It Get The Point, Story Points That Is

By | June 2, 2011

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.

3 thoughts on “It Get The Point, Story Points That Is

  1. Scrum tool

    One of the biggest advantages of using story points is that estimation can be carried out using the Poker method or Fibonacci series. The objective of using the series instead of “man hours” is that the team members have to choose a particular number from amongst those present in the series. If the developer chooses a higher number, he or she is required to justify it – something not possible to do when many hours are used to calculate the velocity. It creates a foundation for further discussion between the team and the product owner, an activity much essential to scrum. When additional discussion is fostered, it leads to a clarification of certain technical issues and the acceptance criteria linked with the user story to be developed. I guess using “man hours” may seem to be more ideal at a first glace since the individual may feel more comfortable to estimate using time. However, from scrum implementation point of view, story points would prove to be more meaningful since the team is required to justify its estimation.

    Reply
  2. Allan E. Dean

    Story points can be very helpful when they are simply relative, hypothetical units of intangible effort – not simply man-hours. Example: early in a new undertaking folks that will have to do the work may say, "Y is harder than X. I don't know yet how much harder, but they definitely are not the same effort." So to move the team's conversation forward, maybe propose adding a research task (due diligence on X versus Y) to arrive at a better estimation. Grooming.

    Reply
  3. Rick Austin

    Agreed, Allan. Disconnecting these nebulous units of time from real time tends to be a real challenge for new teams. They so want to relate story points to days or hours, along with all of the disfunction's associated with that…

    Agree with your recommendation for research stories or spikes to help learn something that allows the team to come back and estimate stories that are difficult because of unknowns.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *