- 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.
2 comments:
The ScrumAlliance mirrors your suggestion on charting. They recommend listing tasks on a Sprint Backlog, and a Burn-Down Chart that tracks their progress. Throughout their suggested framework, they stick with tasks.
Stories are better suited to grouping and prioritizing tasks. They are more closely related to milestones. I often have grouped tasks.
Before adopting Scrum, I made a progress chart for the team's product. As the team (frequently) discovered more work, the progress chart started to resemble a mountain climb. I found this demotivating. Scrum's Burn-Down Chart was a wonderful reversal. With such a chart, I can project a "0 date", when the team reaches a planned milestone. It helps manage scope. We stopped closely tracking time spent, though when a sprint ends with incomplete tasks, we reflect on what took longer and why.
SCS has small Scrum teams of 2-3 developers, one of whom fills the role of ScrumMaster, and 0.1 testers. Scrum recommends a team of 5-9. I applied the book Crystal Clear to reduce overhead. It resulted in a leaner Scrum process which fit our team size.
I use a burn-down chart for major milestones. Currently I have 2 burn-down charts: one for bugs, and one for the next major version of our product. The latter shows whether the team can actually deliver that version on time.
Though Scrum recommends a burn-down chart for each sprint, I have foregone it. More overhead. I feel that level of reporting is less valuable to our team. Contributors and I see when we are in danger of missing sprint goals without it. To date, our small team has performed well.
Is a Sprint Burn-Down Chart valuable for the Product Owner? Certainly. Especially early in a project. But recall that a sprint is like a military insertion point. I conject that if the Scrum team can consistently deliver what was promised at the end of the sprint, the Product Owner will be pleased.
When productivity is a concern, a sprint burn-down chart is a solution.
Thanks for sharing your team's processes and learnings.
Post a Comment