By: Kendrick Burson, Agile Coach at cPrime
Every team I have ever worked with uses post it notes for planning, and most use these notes for a physical sprint task board that they reference in their daily standup. The physical notes provide a more tactile, visceral connection with the stories and tasks throughout the sprint. These post-its are generally only used for sprint planning and this sprint task board, not for general product backlog work.
Story cards contain a header band at the top that allow the story id (from online tool such as Rally or VersionOne), a story name, owner priority and team estimate. The rest of the card is given to the story narrative, and maybe the acceptance criteria (which are often put on a separate note, paper or on the back of the card).
The task card that teams I have used usually have a similar header [Story ID] [Task ID] [Estimate in Hours]. The rest of the card is used for a brief description of the task. These cards are always the smaller 3×5 or 3×3 cards to limit the information put on the card (avoid analysis paralysis).
When used in Sprint planning, the Scrum Master will have the story cards pre-printed or filled in with all the information from the sprint backlog and attached to the wall, laid out for easy viewing. The team reviews each story and discusses the design details with some Q&A with the product owner or Subject Matter Expert. This process often involves modification to the story or acceptance criteria (especially if the story was not previously groomed). Once they are comfortable they vote on an estimate; often they accept the pre-existing estimate from backlog grooming or affinity estimation exercises that occurred earlier. After they have reviewed established estimates for enough stories to fill their sprint (according to team velocity or capacity) they then turn to task break-downs.
For the task-break down, they return to the top story and discuss what tasks would be necessary to accomplish the story as specified. This usually involves deep discussions on design and architecture. The Scrum Master is often challenged to hold the team back from diving too deep and getting lost in analysis paralysis. Mature teams will break out into sub groups, pairs or individuals to do task breakdowns on multiple stories in parallel (one sub-group per story). After the stories all have guestimated task breakdowns the team reviews each story with their task breakdown and makes modifications as seen necessary by the team as a whole. In the end each task is ratified for appropriateness and communication of intent as well as estimated in hours to complete. These task estimates are then rolled up and compared to the story estimate (in story points) and reviewed if adjustments in the story estimates are necessary.
After sprint planning, the story cards and task cards are often placed on a sprint task board. This sprint task board is used to communicate, track and manage the sprint backlog throughout the sprint progress. Developers will move individual task stickies from a pending or ‘to-do’ state through ‘in-progress’ to a ‘done’ state. Finally, after all tasks for a story are completed the story is reviewed by the product owner and the story card is moved to ‘accepted’, or new tasks are created to finish the story to the product owners satisfaction.
At the end of the sprint, all the task and story post-its are thrown away and sprint planning begins anew with new stories pulled from the top of the product backlog. In order to maintain historical reference data, and for broad communication, the product backlog and tasks are maintained in parallel in an online tool such as rally or versionOne. In many teams, the Scrum Master volunteers to maintain the online tool to free up the developers to write code.
Post-it notes have been used for the past decade to manage iteration work details. Online tools have been appearing to help organize, manage and mine this data as well as make it accessible to people located outside the team area.
Get your own cPrime Story and Task Template Set