I’ve been practicing agile for years, but always with the lead of a strong scrum master or one in training with a good mentor. There are things that I just simply assumed were “the way things were done.” As a product manager and the product owner, my main concerns were that there was a well groomed backlog, joint understanding of the stories and the overall team velocity. I left the rest to the scrum master and the team, and I cared about the burndown.
Besides Explaining Scrum in less than 120 seconds from the previous post, I also found a Simple Cheat Sheet to Sprint Planning Meeting. That post doesn’t talk much about the units of capacity, but I’d always seen it as hours. You then estimate hours available, counting vacations and known reasons for being unavailable beyond the work of the sprint.
What I found was that the team was estimating tasks in story points, and working to make sure that the sum of the points for the tasks matched the number of points for the overall story. This led to large tasks and the lack of numerically measurable and perceptible progress. There was no burndown or burnup chart.
Mike Cohn describes this well in his posts “Why I Don’t Use Story Points for Sprint Planning” and in his description of the sprint backlog. This page and others in the series do a great job with the concepts of agile. Mike also has a Powerpoint presentation Introduction to Scrum available on Mountain Goat Software’s site. I especially recommend slide 24 on sprint planning and slide 30-39 on the product and sprint backlog. I’ve put thumbnails of these slides on the right. Thank you, Mike, for your very clear presentations, graphics and examples of Scrum.
I now know why the recommendation is to move from points to hours in sprint planning. The process always needs to be concrete, and mapping the work to the people and their schedules and availability is key.
Addendum: People pointed out a blog by Jeff Sutherland on this topic, titled “Story Points: Why are they better than hours.” Any blog entry with 75 comments has got to be interesting. In the comments, Jeff points out three ways that a team can work
- Backlog in story point and no tasking (hyperproductive teams)
- Backlog in story points and tasks in story points (best current practice as teams are getting better)
- Backlog in story points and tasks in hours (the old way)
In other words, you start at #3 and work up. I’d also believe that the effectiveness of #1 is proportional to the size of the stories (smaller stories makes this more possible).