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. Kent McDonald explains how using visualization boards can help in these situations.
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.