Agile: The Story Board

The story board…

If you have used Agile for Project Management or Software Development, and used Scrum, you probably have heard of the “Story Board”.

Trek BI Agile Story Board

Funny thing though, I have talked to a few people that have came through and they saw the boards we have and it was “oohh I have never seen one in real life”.. but yet they have run or been involved with scrum before.

So what is the deal with the “board”?

  • The Board is a focal/gathering point
    Every day at your standup/scrums, you should bring the board in and use it as a tool. Also at the sprint planning. Think of it as another team member. Talk to it. Talk in front of it, analyze it, adjust it, show it off, explain things on it to people
  • The Board shows tangible evidence of results
    You should hang your velocity and burndown charts on the board, you should have a nice full current and next sprint that changes every day as people do things and new items get prioritized. Your backlog should be filling up. Communicate your iteration dates and maybe other key info, but most important, if someone walks up, they can see your burndown.
  • The Board is a talking point
    People around the office start asking “What is that thing?” People in other teams want to know what is up. Other people might come up and ask where things are at, or where their “story” might be. You can use the board to start discussions on agile and also about your project
  • The Board let’s your focus
    As a developer or “do’er” for your project, you can focus on just the current sprint. You can focus on the cards on the board. You see slightly what might be coming in next sprint, but you are focused. As a product owner or team lead, you can see progress and focus on the current 2 weeks.
  • The Board makes it tough for distributed teams
    If your team has some members off site part of whole of the time, then it is harder for them to actually “use” the board. They need a virtual board as well. They need virtual stories or some way to update progress.
  • The Board adds a little overhead for Scrum Masters
    With a online system or virtual system, the Scrum master can update things there, and so can the developers. With a board, and especially with a board + virtual system, the scrum master has to make sure things are in sync. What should they focus on? The board or the virtual system? Both. But since the board is visible to EVERYONE who might walk by, they need to make sure it is up to date and in working order.

My thoughts: The board *should* exist, you *should* use a board.

But, what if you run distributed teams? Then.. if majority of them are not on site, then use a virtual board. If it is a mix, use a physical and virtual board.

But what if we don’t have room for a board? Then make room.

But a board costs money. Not really. I made one out of things lying around the office. Minimal cost. You can expense story cards, etc.

But xyz.. well, I am sure there is an answer.

If anything, start with a board, and cards (another blog post on that) for at least one year, and then look at going virtual, *if it makes sense*. I still think the use of the physical board is a key part of the process, but like with anything Agile, the process always differs by team and project.

You can always roll the board somewhere to demo. You can show the board to anyone. Any worker, any executive, a group of many people, or small. You might not be able to do that with a virtual system: you might be limited by number of accounts or other system limitations.

The board might be a “relic” of agile, but I think it lends itself to running the process in a way many can understand, without having to learn any software, and also lets your team communicate progress and results easily. Use a board? Just do it.

Business Intelligence Work

Agile in Business Intelligence? Of Course!

About 3.5 years ago I was introduced to Agile at the Agile 2006 Conference. After that, and implementing it in a software dev environment, I found that it just works. Sprints, Scrums, Stories, Backlog, Velocity, all the pieces fit and work.

Now that I am managing a Business Intelligence group, which when I started wasn’t doing *anything* as far as a method, I had to ask myself if doing Agile would work (I knew it could, but it is different than software dev in many ways, similar in others).

Back in October, my group went Agile. We set up a board, got some index cards, and just started Agile. A big paradigm shift at work for IT, but we needed to do something.

With Business Intelligence, we really don’t have *code* to work on, but more “objects” (Cubes, Dimensions, Reports, etc). As a team we needed to figure out – what is a story? What is a feature/enhancement/task. What is an epic? How are we going to score things, etc.

The first few sprints (2 week sprints – Wednesday’s to Tuesdays) our velocity was lower and/or we just scored things a little weird. But since then we have learned our “zone” of scoring stories and we got into a groove of releasing our BIG cube every 2 weeks, and releasing the smaller changes when completed.

We do the daily *scrum* for 15 minutes, and track burndown on stories, which lets us make some cool burndown charts that we tack up on our board, and we have some other cool bullet charts to track velocity by sprint, to our original, and final goal, and more.

What has Agile brought our group? Confidence, Stability, Ability to Meet Expectations. Agility. Results. and more..

Do we run into issues yet? Of course. Can we adjust and handle them. You bet! Are we continuously learning and changing our process to make it better? Yep. Always room for improvements.

What else does Agile bring us? Visibility to our customers, and to our peers in IT. Eventually the “BI” stuff should just run, over and over, iteratively.

Trek BI Agile Story Board

Agile isn’t a silver bullet though. It isn’t easy. You still need to work to keep things organized and on track. You have to fight that organizational gravity that sucks teams back in and people in as well, and throws that scope creep back onto stories and projects. You also have to fight to get rid of your technical debt, which depending on how long things have been running before you started even thinking about Agile, might take you a while.

This post is more of a high level “Yes We Can” type post about Agile in BI. I haven’t decided yet, but my guess is I might have some more detailed posts on how I like to run an Agile project, and what we are doing as a team to handle situations that come up, and just how we do things.

In the end though, just remember, have fun!