When practicing Scrum, we can make the sprint backlog visible by putting it on a Scrum task board. Team members update the task board continuously throughout the sprint; if someone thinks of a new task (“Test the snark code on Windows 8.1”), she writes a new card and puts it on the wall.
Either during or before the daily scrum, estimates are changed (up or down), and cards are moved around the board.
As an example, the Scrumboard looks like this:
Each row on the Scrum board is a user story, which is the unit of work we encourage teams to use for their product backlog. During the sprint planning meeting, the team selects the product backlog items they can complete during the coming sprint. Each product backlog item is turned into multiple sprint backlog items. Each of these is represented by one task card that is placed on the Scrumboard. Each task card starts on the Scrum taskboard in the “To Do” column.
The columns we generally use on a taskboard are:
Story: The story description (“As a user we want to…”) shown on that row.
To do: Place for all cards that are not in the “Done” or “In Process” columns for the current sprint.
Work in process: Any card being worked on goes here. The programmer who chooses to work on it moves it over when she’s ready to start the task. Often, this happens during the daily scrum when someone says, “I’m going to work on the boojum today.”
To verify: A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card, there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t get corresponding test cards (“Fix Bug No. 321 in Bugzilla”) so those are placed in the “To Verify” column.
Done: Cards pile up over here when they’re done. They’re removed at the end of the sprint. Sometimes we remove some or all during a sprint if there are a lot of cards.
Optionally, we sometimes use the following columns on a Scrum task board, depending on the team, the culture, the project and other considerations:
Notes: Just a place to jot a note or two.
Tests specified: We like to do “Story Test-Driven Development,” or “Acceptance Test-Driven Development,” which means the tests are written before the story is coded. Many teams find that it helps to have acceptance tests identified before coding begins on a particular story. This column just contains a checkmark to indicate the tests are specified.
Here are some photos of actual task boards in use.
A Scrumboard hanging in a team room: