How Do You Handle Planning and Estimation?
David Starr had a good post this week on planning future work cycles. Do you use a team's commitment to the next iteration or the team's historical performance?
Sprint Planning, Velocity and Reality
David makes a compelling case for using the team's willingness to commit over their historical track record, and I agree that a team should always have input into the next iteration's goals.
However, I can't help but wonder if the balance would change if we had access to real, accurate numbers on exactly how long every feature (or bug fix) took? The 6th Sense Analytics toolkit tracks, down to the minute, how long a file was in edit and debug mode. We add up that time and then present you with a factual (not guesstimated) level of effort that went into building that widget.
Instead of saying this feature was 5 story points and it was done in, oh, I don't know, 3 days, he'd see a report. And that report would say this feature was done in 12.3 hours over 3 days. Instead of looking at calendar days and estimating amount of work, we can very precisely list a daily velocity (by hours on the computer) by team or by person.
Our burn-up chart can very cleanly show you project status on an hour by hour basis. The trends that the yellow line (the actual time worked) will quickly show you whether your team is trending towards an on-time delivery or whether they'll blow the deadline out of the water.
The blue line, the scope, shows you feature bloat (the line climbs) or feature flux (the line shoots up and down repeatedly, like the stock market on bad day). The red bars at the bottom shows you how much you actually completed. There's usually a gap between scoped work and completed work.
We also present each task with an estimated versus actual report. This type of information helps many teams move past story points and into into real hour estimation. Story points are a nice approximation but it takes hours on a keyboard to complete a feature. White boards are vital. Brainstorming is irreplaceable. But if you don't hit the keyboard, the code never gets done.
Would you still use story points if you could really measure hours per feature? And would historical performance be weighted more heavily if you actually knew how long each feature took?
Next week I'll post my favorite graph, the Debug-Edit-View report. The DEV report shows you whether or not your developers are on track or stuck, and how to get things back on track.
Previous Post:
Our Senior Developers Aren’t Writing Code Anymore!
Next Post:
6th Sense Analytics - New & Improved!
