Should story points be a measure of complexity or effort?

In the last affinity estimation session I was in we had an interesting debate on whether story points should be a reflection of complexity (how difficult something is to develop?) or level of effort.  I realized that for many starting out in Scrum it can be very confusing why story points are used instead of hours, which is what most traditional development shops tend to use and what they represent.  In this post, I’d like to address two commonly asked questions regarding story points:

  1. What are story points?  (measure of complexity or effort?)
  2. Why are they used instead of hours?

What are story points? Story points are arbitrary measures for the amount of work to be done to complete a story (or feature).  They are usually unique to the team assigning them, meaning you can’t compare points from one team to another.  Note that it is certainly possible for two or more teams to have similar point values by using the same “anchor story” to base their points on but even if this was done, it is not advisable to compare points and velocity (how many points a team can complete within a given sprint or iteration) for many reasons (See Misuse of Velocity in Agile Projects).  When coupled with a team’s known or projected velocity, it can be used to help inform the product owner and key stakeholders on when features could potentially be delivered.  The most important question story points help answer is, “When can I get it?”.  Knowing the complexity of the story doesn’t answer that question.  Although, understanding complexity is important.  Typically highly complex features tend to have associated risks in the form of performance, security, testing, etc… that need to be actively managed.  But when it comes to story points, it’s effort and not complexity.

Why are story points used instead of ideal hours? Before I answer, I’m assuming that you are familiar with the cone of uncertainty in software estimates.  If you are not then I suggest you read this article (Software Estimation and the Cone of Uncertainty) or do some googling.  =)  Also keep in mind that this is a heavily debated topic with leaders in the Scrum community and that there are books solely dedicated to agile estimating so take this for what it is, a simple blog post.

As mentioned above, story points are arbitrary measurements of work.  Hours are actual measurement of time.  How many times have you been in meetings where developers argue over the amount of time it takes to perform a development task?  Too many to count right?  Points are an easy and effective way to size the amount of “work” required for a story irrespective of time.  How quickly can it be done is not a question of size but a question of velocity. Because hours are a unit of time, it makes it difficult to use as a measurement for size.  Where do hours come into play?  The teams I manage assign hours to their tasks during sprint planning.  This helps them track their progress during the sprint by indicating how much work is left to complete.  Why use hours and not points for story tasks?  I’ll answer that simply by saying at this granular of a level in planning it’s easier to use a meaningful measurement like hours given that the teams have a much better understanding of the work.

Hope this helps!  Happy sizing!

For more information on story points and hours, check out Mike Cohn’s blog post – “It’s Effort, Not Complexity“. 


Advertisements

About mtang35

Technology professional and leader with extensive experience in the telecommunication industry. Worked with Microsoft, Oracle and Adobe technologies to deliver mission critical transaction based customer care and retail sales business solutions. Primary strength is in agile software development methodologies and engineering best practices such as Scrum and Extreme Programming (XP). Interested in supporting organizations that want to become more effective in their software development practices. In my current role, I am supporting 6 delivery teams comprised of 60 technologist including software engineers, software test engineers, scrum masters and system analysts in a distributed development environment. Team members and internal partners are distributed across the US and India.
This entry was posted in Agile Estimating and tagged , , , , . Bookmark the permalink.

4 Responses to Should story points be a measure of complexity or effort?

  1. yash says:

    Good one Mike. I enjoyed reading your first blog. You wrote teams can have different story points measurement. Should Story point estimation be baselined?

    • mtang35 says:

      Thanks for the comment! =) To answer your question, yes and no. If you have multiple teams working together from a common backlog then you would want the teams to have the same story point values. In other words a 5 point story means the same amount of work for each team. This is normally achieved by using a story (often called a “reference” story) that all teams agree to be a certain size. If the teams are not working from the same backlog then there isn’t a lot of value in attempting to baseline the points.

      If you do have a common baseline on story points then be careful in how you use it. See above on “Misuse of Velocity in Agile Projects”.

  2. Arun Prasath says:

    I am in search of a blog, which can convince me that why story point estimation better than hours.

    Mike, the blog is really convincing, why we have to go for story point. 🙂

  3. Pingback: Using Scrum Methods with IBM DevOps Services | ppatchanee

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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