Skip to content

Story Points vs. Development Hours

October 18, 2011

scale64When transitioning from a traditional methodology (or none) to Agile, one of the big hurdles to get over is story points.  Many teams I have worked with struggle with the concept of points at first and have a difficult time deemphasizing development hours estimates.  Once the teams see the ease and value of points, the transition is much easier.

The following questions seem high on people’s lists:

  • What are story points and why do we want to introduce a new unit of measure?
  • Why are points better than development hours?
  • How can points be used to improve management of products and project?
  • Do I need to use both points and hours?
  • Is there a conversion factor between points and hours?

What are Points Anyway and why introduce them into the mix

Story points are an arbitrary scale applied to user stories to define relative size and complexity of a each story as compared to other stories.  Story points used in conjunction with team planning and execution can utilize the past performance (velocity) as a guide to planning the future.  Relative project scale and the number of iterations to complete the work items gives an equivalent to a traditional timeline and progress measurement.

Story Points ARE:

  • Story points are a measure of relative size and complexity
  • Story points are unit less, meaning as a scale, they are only valuable to compare against each other within the same team
  • Estimating in story points allows/encourages everyone, including business people  to participate in the estimation process (using Planning Poker)
  • Estimating in story points is FAST and EASY.
  • Story points initiate high-level discussions about everything that is involved in a project
  • Earned points can be used to generate the teams VELOCITY which can be used to predict future work capacity

Story Points ARE NOT:

  • Story points are not directly correlate to development hours
  • Story points do not reflect which developers are used to complete the story
  • Story points are not directly reflect the number of team members who participate in completion of the story

I provide an example below to show the concepts of story points applied to painting the rooms in a house.

In the following example, a team wants to paint the rooms in a house.  The points estimation process started by picking a room (bedroom 2) and assigning a reference points value (5pts).  From there, the team reviewed each of the rooms to be painted, and compared the relative size to the reference room.  If the room was ~1/2 the size of the reference room, we estimated the next scale down (3pts).  If the room was ~2x bigger, the team estimated the next scale (8pts).  The remaining rooms were estimated based on our reference and previous estimates until the house was fully estimated.


The total story points for this project is 8 + 5 + 13 + 8 + 3 + 5 + 1 + 2 + 3 = 48pts of scope.  Notice we did not include information about the experience level of the painters or the number of painters per room.  Complexity was factored into the hall for the number of doorways, and the kitchen for complexity of painting around appliances.  We simply estimated the relative size and complexity of each room compared to the others to determine total scope.

Next will apply a team’s velocity against the points to determine the burn-up/burn-down to complete the work.  In this case, team can earn 13pts of scope per iteration so the timeline is four iterations.  Velocity is determined by past performance.  If this was the first house to paint, the team would make an educated guess at velocity.


Why are Points Better Than Development Hours Estimates

My feeling is that points are not better than estimated hours, just different, simpler, and more universal.  So why are they better?

Story points abstract scope from development effort giving everyone on the team a chance to participate and understand the the size and complexity of software product development.  Here are some other reasons.

  • The business team can help in the estimating process because they don’t need intimate knowledge of the painting process; only relative scale.
  • The estimating process is much faster because we are not bogged down in technical implementation details.
  • Once a reference is established, this process can be re-used for future efforts by the team.  The points allow us to predict the future based on the past.
  • There is no exactness applied to estimated points, but the difference between each point value is a scale of 2x.  This gives some wiggle room that hours simply don’t have.  Because of the scale of the numbers, complexity is accounted for.
  • Estimated hours are not more precise, and a lot more difficult to obtain because a detailed implementation discussion must be conducted to determine the tasks involved to complete the story.

How can points be used to improve management of products and project?

Story points are introduced when planning iterations, and releases.  They are locked into committed stories during the iteration planning meeting.  Story points are earned when stories are accepted by the business.  This means the team designs, develops, accepts, and packages for the story for deployment.

The Scrum Master uses earned points to generate the team’s velocity trend.  Velocity is the key to planning future efforts.

Product managers use points (along with velocity) to guess at future project timelines using burn charts to show the number of expected iterations it will take in order to deliver a set of stories.  This would be difficult, if not impossible, by utilizing development hours because everything would need to be understood at a detailed level, broken out into development, QA, etc.. tasks, estimated, graphed on a project timeline considering resources.

Do I need to use both points and hours?

This is a healthy debate to be had.  My opinion is generally NO. 

Hours can be helpful when:

  • Hours may be estimated at the story level in order to provide a quote to a customer.
  • Consulting companies may need to estimate hours because more and more companies want to know what it costs to complete a project.
  • The development team may be more familiar with estimated hours to determine capacity when looking at the details of stories.  We use the hours estimate on tasks to ballpark development commitment.
  • Development managers may use hours as an indicator about who it actually working on what, who might be overloaded, and who might have bandwidth.

Beyond the above, my teams have done away with estimated hours as a measure of anything.  I use velocity to determine the number of story points a team might earn for an iteration, and use that as a guide when the team is selecting stories to commit to.  When we are close to capacity, I go around the room and ask people how they feel their workload and the confidence in the selected stories so far.  If the team feels light, we commit to more stories.

Is there a conversion factor between points and hours?

The short answer is NO.  There is no correlation between story points and hours and there never should be.  I always discourage anyone from trying to find a connection.  That said, there are ways to use points participation (a trend anyway) by developers to determine the percent of time spend in categories over time.

For example, I worked at a company a while back that wanted to know the amount of time each developer spent developing on each product line for the previous month.  By adding the total points participated in for each member in each product line and dividing by the total points earned by that member, a percentage can be derived.  Multiply this percent to the total developer hours in a given month to show approximate hours spent toward each product line.

Is this accurate?  Not really, but all things being equal, it does provide a really reasonable estimate in a very short amount of time.  Because the hours vary with every story, this works best on longer timeframes so the averages over or under estimates wash.


From → Agile Theory

One Comment
  1. Richard Chipman permalink

    Yours is the first article I’ve read on his subject that clearly explained how to relate story points to effort/time. Estimating effort & time is an anathema to most agile practitioners, but still a necessity for managers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: