Sprint Backlog

Sprint Backlog Format
The most effective format for the sprint backlog is a wall-based taskboard! Find a big wall, tape up a big, big sheet of paper (at least 2x2 meters, or 3x2 meters for a large team).

Convert this space into a table where each row represents a product backlog item in descending order. Include the following columns:
 * **"Not checked out":** Stuff that nobody is working on today
 * **"Checked out":** Stuff that somebody is working on today
 * **"Done":** Stuff that nobody will work on any more
 * **Sprint Goal: "something":** Includes the following:
 * **Burndown:** Manually plot a new point on the burndown every day after the daily scrum
 * **"Unplanned items":** Tasks that aren't planned... These are useful to remember when you do the sprint retrospective
 * **"Next":** If all backlog items are completed before the sprint ends, add new ones from here

You could of course add all kinds of additional columns. However before you complicate matters, think deeply. Is this addition really, really necessary? I've found that simplicity is extremely valuable for these types of things, so I only add additional complications when the cost of not doing so is too great.

Sometimes, for larger teams, a task gets stuck in "checked out" because nobody remembers who was working on it. If this happens often in a team they usually introduce policies such labeling each checked out task with the name of the person who checked it out.

Burndown Chart
The burndown chart shows:
 * The number of story points remaining (y-axis) for the sprint. For the first day, this is in effect the estimated velocity of the whole sprint.
 * Dates, not including weekends (x-axis).
 * A dashed trend line.
 * Dots that shows the progress at a specific date.

Taskboard Warning Signs
The scrum master is responsible for making sure that the team acts upon warning signs such as:
 * The graph is way above the trend line. Need to remove some backlog items from the sprint.
 * The graph is way below the trend line. Need to add some backlog items to the sprint.
 * Top-priorities are not checked out, low-priorities are.
 * There exist a lot of unplanned items. These are killing the sprint.

Traceability
If you must, take a photo of the taskboard every day. But I suggest you really try to estimate the actual value of detailed sprint traceability. Once the sprint is done and working code has been delivered and documentation checked in, does anyone really care how many stories were completed at day 5 in the sprint?

Estimating Days vs. Hours
Most books and articles tell that tasks should be time-estimated in hours, not days. We've stopped doing that, at least for our teams, for teh following reasons:
 * Man-hour estimates were too fine-granular, this tended to encourage too many tiny 1-2 hour tasks and hence micromanagement.
 * It turned out that everyone was thinking in terms of man-days anyway, and just multiplying by 6 before writing down man-hours.
 * Two different units cause confusion. "Was that estimate in man-days or man-hours?".

So now we use man-days as a basis for all time estimates. Our lowest value is 0.5, i.e. any task that is smaller than 0.5 is either removed, combined with some other task, or just left with a 0.5 estimate (no great harm in overestimating slightly).