Heather McLean

A while back, Mike Cohn posted a concise explanation of how story points relate to hours. It’s a common phenomenon; folks who are used to traditional project management really want those points to equate directly into, “how long will this take?” The important thing to remember is that story points are a measure of capacity and effort, not time. The next thing to remember, and this really messes with teams new to agile methodologies, is that story points are mostly meaningless until you have accumulated historical data. Without some data on trends, a story point really is a guess; what does 1 point mean versus 8 points when this is your very first iteration? You have to go on gut feelings, and there will be resistance to that kind of “guesstimation”—which is pretty sad when you realize that guessing hours is not much better than guessing points.

At least with the points, you’re admitting that it’s an estimate. Hours tend to lull people into a false sense of security, assuring them that this is the timetable, and if you deviate from the established time line, then it’s the implementers’ faults, not the estimators’. Which brings me to another important part: story points are estimated by the team, not by a single project manager dictating from on high. This puts the onus on the team to estimate better with each sprint (which they will, given the freedom to do so), instead of being forced into a death march to meet arbitrary time limits.

Estimating story points is an ongoing learning experience. You start with none and build from there; once you’ve had three or four iterations under your belt, you’ll notice the team getting more accurate. All one point stories will start to look similar and take similar amounts of time, and once you have that in your arsenal, estimating with the story points both generates a realistic timeline and gives your team some breathing room.

So I’ve gotten really used to the idea of thinking in terms of individual stories/tasks when I work, and I like the visual cue of a task board. I haven’t been able to convince everyone that this is the best idea yet, so I’m leading by example. Here’s a shot of my “personal task board” that I have in my workspace.

Personal Taskboard

You can see several columns from right to left: NR (not ready/undefined), Rdy (ready to implement), WiP (work currently in progress), and Done. The tasks are written on individual sticky notes with a description, the ID number from our defect tracking system (if any), and the product release it is assigned to (if any). They’re assorted roughly in priority order with higher priority items towards the top of the board.

I wanted to take a minute to pass on a very insightful article by Tobias Mayer:

Oppression, Revolution and the Future of Scrum

I won’t add any commentary this time, just go read it for yourself.

As an aside, I realize that this is a pretty weak post in light of my long stretches of silence. My current project has me pretty busy, but hopefully I will have some more discussions on agile and whatnot in the near future.