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.