Agile Government Leadership
The Storyboard is a Big Visible Chart that is really the heart of a sprint or workshop.
The storyboard helps everyone keep track of which stories are new, in backlog, in progress, or done. It must be where everyone can see it. A whiteboard with sticky notes works fantastically well for this, especially for a workshop or exercise. Later, in real-life projects, you will probably want to use a tool such as Trello to keep track of projects.
The storyboard has lanes. Each lane has a list of stories that are ready to be worked on by members of the team. A story is moved from one lane to another, usually but not always forward, by the people working on the story.
The sections of a storyboard are labeled:
- In Sprint
- In Dev (Progress)
- In QA (Test)
As you can see, there can be variations in how these boards are done, depending on what works best for the team. But they have much in common.
All storyboards must:
- Be big, visible, and clear
- Feature the highest priority stories at the top of the list
- Contain sections for Backlog, In Sprint, In Progress, Test, and Done (expressed in a way that makes sense to the team)
Remember to always keep the highest priority stories, visually, on the top of the list in each lane. The developers need to quickly reference the order in which they should tackle each story. Also, use language that the team understands most easily. If your team spoke Russian you wouldn’t do a board in Greek, so if the local culture needs to call “QA” something like “Pending Verification” — that’s fine.
The Product Owner can put a story into the backlog at any time. The PO and others on the customer-facing team should be constantly “grooming” the backlog for stories ready to be placed on the board, based on changing business needs or because they have been able to complete a story with enough detail to be worked on.
Stories move from “Backlog” to “In Sprint” at the beginning of the sprint based on priority (and the estimated available capacity of the team to fully complete the stories within the sprint’s timebox). There should be about 2 sprints’ worth of stories prepared in the backlog before the first sprint begins, along with some additional “stretch stories” that are ready to go, in case the team is working faster than predicted.
When developers begin working on a story, place the story “In Dev”. When a developer has finished coding a story, he or she should show it to a customer-facing person, who will place the story “In QA” if they agree the story is done.
At the demo, each Story which is “In QA” is demoed. If there is any question, do a simple voice vote of the customer-facing team only, and if they believe the story has passed, move it into the “Done” column. If not, move it back into the “In Dev” column.