- Radiate information.
- Clearly communicate whether the sprint is on track and likely to conclude successfully.
- Alert us to lurking risks, so that the team can react and adapt proactively.
- Tell a story about the sprint from which we can learn during our retrospective.
Instead of moving user stories through phases (development, review, testing...), list their tasks. Tasks for a story could include testing and reviewing pieces, merging code into previous versions, meeting with a product owner to review the UI and clarify requirements, or convening a design session. You can add tasks to the list as they are discovered, which can signal that a story is ballooning or that a technical problem is thornier than originally estimated. If there are certain steps the team is trying to get more rigorous about (like writing unit tests before writing code), you can list them as explicit tasks until they become second nature.
Each day, estimate the number of hours remaining in each task. Not the hours spent, and not a comparison of estimates to actuals. This is not about "metricking estimation accuracy" or some other useless bean counting; it is about ascertaining right now, today, how many hours' worth of work is there left to do, and will that fit in the time we have left.
The hours remaining on a task might go up. (Ever peel back the wainscoting on a piece of code and find it's all termites underneath?) New tasks might get added during the sprint. The reason to track the hours remaining is so that you can adjust when you spot a potential problem—perhaps a team member is getting pulled away with other work, or is stuck in a mess of code that your expertise could alleviate, or maybe it's time to negotiate a trade-off with your product owner. To deal with any of these effectively, you need to know, if you'll pardon the vernacular: Where we at?
In the sample task list above, you can see that we're not only showing the hours remaining, but also tracking the movement of that number day after day. That allows us to make a graph, creating that visual heartbeat we're looking for.
At the end of the day (or completion of a task), update tomorrow’s column for the number of hours remaining for that task. If you finish a task on Day 4, then at the start of Day 5, there are zero hours remaining for that task. New tasks that crop up unexpectedly should show a zero until the day on which they were discovered, and then an hours-remaining estimate until finished.
The graph plots each day's sum of estimated hours remaining. It also shows an idealized burndown line, as if the team were completing [original hours estimate / number of days] worth of work each day. This makes the picture clearly communicate whether you're in fair weather or potential trouble.
If estimating hours remaining seems daunting, split the tasks into smaller pieces. A task should fit within a day, and the work you claim in the morning stand-up should fit within a day.
Time tracking is a sensitive topic, and suggesting it may not be well received by the team. Despite good intentions, many organizations use time accounting policies abusively. Superstitious beliefs, uncharacteristic vehemence, and irrational resistance are indicators of prior abuse. There is a tension between the two Agile tenants of transparency and self-organizing teams: I don’t want to hide data from you, but if I let you see the tools we’re using to track our progress, you’re liable to interfere, draw wrong conclusions, or base bonuses and promotions on them. These are not flaws in tracking sprint progress, though; they are deeper organizational issues, that are worth correcting and rehabilitating so that the team can take advantage of a burndown chart's benefits.
A graph tracking your team's completion of work gives you a picture of the state of the sprint, making it easy to see if you're on track to succeed, and alerting you to struggles early enough to react.