How Visualization Boards Can Benefit Your Team

User stories are often described as promises for a conversation, and sometimes teams need a reminder whether they have had the conversation or not. As agile is adopted by more organizations in an enterprise setting in which the software assets the delivery team works on are fairly complex (sometimes just plain complicated) and contain a lot of interrelationships with other systems, those conversations may have multiple parts with several different players. Ellen Gottesdiener and Mary Gorman, in their book Discover to Deliver: Agile Product Planning and Analysis, provide great advice for how to have structured conversations. While many teams can use help structuring their conversations, some teams also need some way to know whether the structured conversations that have taken place have provided sufficient information.

Many teams use visualization boards (a term coined by Olav Maassen, Chris Matts, and Chris Geary in the book Commitment: Novel About Managing Project Risk) to track the progress of the stories as they move toward done. I have found that many teams (but not all) can benefit from keeping an eye on how things are progressing as they are getting them ready for an iteration. I like to call this the discovery board, because it visually displays how a story is progressing along the discovery path to get ready for an iteration. The name may be a tad misleading, because discovery still occurs as stories are developed and tested, but at that point the primary focus is delivery.

I was working with a team a few months ago that had a steady stream of stories coming in from various sources and the team members found that when it came time for iteration planning, they were always struggling to have enough stories ready. Often they didn't realize this until they got into iteration planning, so they had to spend most of the allotted planning time discussing the details of the story and trying to figure out what the stories were about. As you would expect, they found this frustrating and not very efficient.

To help address that problem, the team members and I sat down and first discussed what information they would like to know about a story when they started iteration planning. We started by generating a list of all the things that would be nice to have locked down before initiating a story, and as we continued that discussion, the team members realized that they probably wanted too many things in place prior to the start of the iteration. They started taking items off the list until they were left with the following: a story, acceptance criteria, testable examples, a mockup (if necessary), the impacted stakeholders identified, and an identified relative size. This became their definition of ready.

Since many different members of the team often took part in identifying and fleshing out stories, some felt it would be helpful to be able to see how far along stories were, in case someone worked on one aspect of getting a story ready and then another team member picked it up and finished it off. The team members also thought it would be helpful to have a sizing discussion on a weekly basis, and though they were comfortable sizing stories that only had the story and acceptance criteria identified, they thought it would be helpful to know which stories were at that point so they knew which ones to focus on during the sizing discussion. Also, some members of the team liked to take a quick look at the stories prior to the sizing discussion; in this case, knowing which stories were next up for sizing would be very helpful to them.

We laid out the various steps that may occur in getting a story ready for iteration and drew those steps up on a board as columns. We ended up with something that looked a bit like this:

Figure 1. Example Discovery Board

Stories began their journey in the New column and stayed there until the team identified a set of acceptance criteria, at which point they were moved to the Ready to Estimate column. We had some discussion within the team about whether to have a Needs Research column, because there were some stories that the team needed to do more work on in order to further understand either the story’s business or technical implications. We decided to not create a column for Needs Research because not all stories would flow through there, and instead used red dots to indicate the stories that needed some form of research; these stories stayed in New until that research was done and an "X" was drawn in the red dot.

Stories in the Ready to Estimate column form the "to-do" list for the weekly sizing session. Since this board was on a magnetic whiteboard with wheels, if the team members had their sizing discussion in an area separate from their team space, they could roll the board to wherever they were having the discussion. During the sizing meeting, as team members sized a story, they wrote the size on the card representing that story and move it over to Estimated.

The Estimated column formed the queue of stories that needed examples, a wireframe, and the rest of the information needed to meet the definition of ready. The team members also decided to start using the Three Amigos technique as the final check to determine that stories were ready, or in their case Ready to Rock. They decided that not every story had to go through three amigos, only the ones dealing with new types of changes or complex changes. Once they had met and decided the story was ready, they would move it over toReady to Rock. If a story didn't need to go through the Three Amigos technique, the team member working on it would simply move the stories to Ready to Rock when he identified the examples, wireframe, and other information included in the definition of ready.

Now, when the team members met for iteration planning, they could clearly tell what stories were ready to be developed and they could focus their iteration planning discussion on what combination of stories made sense for the next two weeks. Their iteration planning became a lot more effective and the team members did not dread it nearly as much as they had before.

Visualizing the flow of stories getting ready did not completely eliminate the problem of not having enough stories ready for the next iteration, but it gave the team members an early warning signal that they needed to be talking to their stakeholders and getting some things prepped. In fact, a member of the team (we may call him…Tim) mainly focused on keeping the stories moving across the board and having the discussions with team members and stockholders necessary to get the right stories (i.e., the ones that produce the most value when completed) ready for the next iteration. The discovery board was a great help to him because he could immediately see whether there were enough stories getting close to ready; if there weren't, he could talk to product management in order to understand the next items that should be delivered from the product roadmap and he could work with team members to get those ideas fleshed out and ready for upcoming iterations. Having a visual display of work getting ready helped the team members to quickly know what should be included in the sizing meeting and whether they should have a sizing meeting at all.

The discovery board certainly helped the team members get a better handle on what conversations they had and which ones they needed to have in order to move forward.