It Get The Point, Story Points That Is

agile, estimating, hours, sprints, stories, story points

Comments Off on It Get The Point, Story Points That Is

So, this story point thing… what’s up with that?

When estimating effort for user stories most people use either ideal hours or story points. My recent experiences have been with ideal hours. This works well but there has always been something that keeps me thinking about the value of using story points instead. I’ve never used story points but I’m increasingly feeling that there is a lot of value and an ability for them to help shake some teams free from rigid past behaviors. Is there anything wrong with ideal hours? Not that I can tell, but I do believe there might be some negative behaviors at play for organizations that are moving to agile software development from more traditional methodologies (e.g., waterfall, etc.).

What “Is” An Hour?

In release planning, teams typically arrange stories based upon some priority which may consider customer value, time to market, effort, etc. Stories are slotted into a release with the release being delivered after a certain amount of sprints have been completed. The number of stories that fit within a release is determined by the team’s velocity. Velocity can be measured in any unit but often is represented in points or ideal hours.

If ideal hours are used to estimate story effort then it is really easy for people to equate these to “real” hours. It is a hard behavior to break. Hours and ideal hours look frighteningly similar. Might someone interpret a 40 ideal hour effort to be something that can be completed in one week? Please tell me you understand why this is not the case.

I have no proof, but might the use story points begin to break this connection to real hours. Since story points are a relative measure of the time needed to implement a story, there is no real connection to hours.

What’s My Velocity?

Regardless of the unit being used to estimate stories, a team will stabilize around a certain velocity. Velocity representing the amount of work a team can complete in a sprint. There will certainly be some fluctuations in velocity which may be caused by holidays or an increase in support activities, but in general, a team will stabilize. One other item to note is that there is usually a difference in velocity across teams. For this reason, velocity is NOT an appropriate measure of productivity.

Where Did The Time Go?

At release planning, each story is estimated using points but once sprint planning is done, the team will use hours. Each story is split into some number of tasks representing work to be done for the story. The detailed tasks are estimated using hours and the team can then determine if they can complete the story. When the sprint planning meeting ends the team has a committed set of stories for the upcoming sprint.

Are We Done Yet?

Each team, and others, are interested in tracking progress during a sprint. Story completion seems like a good measure but often stories are closed at the end of the sprint with the customer which doesn’t really help during the sprint. Since the stories have been broken down into tasks, the completion of tasks provide a good indicator of progress within a sprint. Most team members will update tasks, work done and work to be done, each day. Some sprint planning tools will use task completion and remaining work information to create a burn down chart which shows how well the team is tracking against their sprint commitment.

At the end of the sprint, the number of story points completed is used to determine a team’s velocity. Story completion is the real measure of delivering value to a customer.

Wrapping Up

My initial purpose for writing this post was to try and discover for myself the benefits of using story points. In doing so I’ve highlighted common practices of release and sprint planning, certainly not in detail. At this point, I do believe there is greater value in using story points rather than ideal hours. My thinking is colored by my experiences and the type of organizations I’ve worked in so your mileage may vary. If you have an organization that is moving to agile software development that comes from a place where the norm included big requirements up front, lots of design up front, massive Gantt charts prior to project start (the plan is always right, right?), and similar dysfunctions then the use of story points might assist in the change. You might find that the use of ideal hours creates too strong of a connection to past behaviors. Story points are not a cure-all and will not eliminate unhealthy behaviors but they do cause a shift in thinking that can’t hurt.

I’m game to give it a try.

Come visit my blog and post a comment.