DevOps Zone
DevOps Zone is brought to you in partnership with:

Sean McHugh is a Scrum Master at Axosoft who works with customers who are new to the scrum methodology. He also helps customer's who are experienced with scrum, but are beginning to implement a software solution for their scrum teams. He shares some of his thoughts and experiences at thescrumblog.blogspot.com. Sean is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Should Your Dev Team Stop Using Story Points?

06.10.2011
| 5376 views |
  • submit to reddit

Related MicroZone Resources

Apply Lean to Build & Deployment

Beyond the Buzzwords: Continuous Delivery & DevOps

Why DevOps? Why Now?

Free Download - The Learning Puppet VM

1K FREE Pre-Built Configs

Like this piece? Share it with your friends:

| More

Let me preface this post by saying this: I get Story Points, I understand how they work, how they should be used and the problem that they are purported to solve.

Here's the thing, I'm a minimalist at heart. My first (and typically second and third inclination) whenever I learn something new is to strip it down to it's minimal working moving parts (there's an acronym in there somewhere). With story points it seems that the industry has reached a solution without fully understanding the problem.
Q: So what's the problem? A: Detailed estimates are always wrong. Will always be wrong and can never be accurate except by pure luck.
Q: Why are detailed estimates always wrong?A: Because the real world is a complicated place and it's impossible to see clearly into the future.



Story points answer this by doing something important, they abstract the estimate and allow us to estimate with a larger unit of measurement therefore granting us the freedom to estimate with a lower level of precision.

But the abstraction introduces a new problem. Allow me to illustrate with a couple questions.
  • Why do you estimate?
  • What is the problem with misestimating your work?
  • What is the most concrete and important constraint of a sprint?
Since blogging is a bit of a one way conversation until it's published let me fill in some of your answers.
  • You estimate so that the team has a realistic amount of work in a sprint.
  • Misestimation of a sprint is a problem because the team will not have enough time to finish the sprint backlog if they overcommit due to poor estimates.
  • The most concrete and important constraint of a sprint is time (unless you have a tool that can stop or slow time, in which case I want in on the beta).
So when we look at it objectively, we're actually fooling ourselves by pretending we're not estimating with real time units.
Now in some cases this is a good thing, it's a bit like Mom mashing some cauliflower into the mashed potatoes so we'll eat some real vegetables but I don't see it as something to default to or even a permanent solution to the estimates problem.
So what's the real solution? Combine the best of both worlds.
Estimating in logical time boxes.
Instead of estimating in units of measurements, we estimate in predetermined timeboxes.
A slight tweak should only take a couple of minutes? That falls into the 1 hour timebox. A bugfix should take me the better part of a day? That'll fall into the 1 day time box. What time boxes should your team use? Probably not fibonacci numbers since they'll imply some level of precision which shouldn't be there and tshirt sizes are missing the point of estimating in time as well. The answer is that you should decide with your team but, here are some good ones to start with:
  • 1 hour
  • 4 hours
  • 1 day
  • 2 days
  • 3 days
  • 5 days
  • 2 weeks
At some threshold with these you'll want to decide to split the backlog item into more manageable chunks and you'll want to estimate with the assumption of one person working on an item from beginning to end. In practice there may be multiple hands on that item at any given time but we want to capture total time expended not calendar dates in progress.
So what've we learned? A lot actually.
  1. Detailed estimates are dumb and we shouldn't do them.
  2. Story Points mask the point of estimating and can potentially sow the seeds of confusion.
  3. Estimating with time units isn't that different than estimating with story points since you'll still estimate with distinct values rather than detailed units.
Let me know what you think in the comments.
References
Reference: 
Should Your Dev Team Stop Using Story Points?
Published at DZone with permission of Sean Mchugh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Josh Martin replied on Sun, 2011/06/12 - 6:06pm

Points have nothing to do with time, and using anything besides some tracker applications, you will not understand this. Points are measures of complexity and risk, not of time. Forget anything to have to do with time, and consider risk, unknowns, or possible issues and apply them to the points. Task estimates are where you should be applying your time estimates. I have provided some example below;

  1. Story Points = Measure of risk/effort/complexity.
  2. Task Estimates = Proper task estimates with hourly time.

Do not get them confused! When we want to complete feature X, as an overview estimate, using points is the best thing. 0 for a wording change, 1 for a form field change, 2 for a processing a post parameter (or set of), 3 for adding a new signup form... 50 for something crazy that you have no idea about but are confident with some time you could implement, etc... The usefulness of points exists when you see that a story has several more points than usual (8-13+). This means you should break it down in to a few different stories to reduce complexity and risk that the story may have to the sprint. If you have 13+ point stories, you are either sandbagging your sprint or not even completing them (and I mean full QA and deployed to production in a SASS environment) due to this issue.

Most "sprint" tracking applications do not do this properly, so we have an abundance of developers who try to apply points as if they were time. This is not correct by any means. They are two different concepts. POINTS ARE FOR RISK AND COMPLEXITY NOT TIME!

Take for example: "Add facebook login" as a story. First, we need to hook up oauth, then integrate our authentication system, and finally provide a slick UI. This should be pointed as a single feature, so it will be a single story. I would estimate it somewhere between 3 and 6 points depending on the existing authentication system. This gives product owners an idea of how much effort is needed to complete the feature. It has nothing to do with how long it will take.

Furthermore, tasking out this feature would include exactly what I stated...

  1. add oauth support (~3 hours)
  2. integrate with existing auth system (~2 hours)
  3. dev qa the user flow and clean up UI (~4 hours)

So this example story becomes a 9 hour story with 5 points. Given 5 points is "they know what they are doing, but there may be a few issues that may take longer". If it was a 13 point story, it's probably obvious that your developers are either unfamiliar with oauth, or you have a very complex authentication system. These can be taken in to account when selecting which stories the product mgmt team wants to get in to the sprint, but as far as experience,if you have three 13 point stories in your sprint between a few devs, you are basically doomed because of the multiplied risk factors (unless your point calculations are much different than mine).

Oh, and I don't like cauliflower in my potatoes

Jo Gee replied on Mon, 2011/06/13 - 5:22am

I totally disagree with this post.

When you measure a story with x story points, the time that (x/storypoints) represents is variable. In the end the project manager will have a pretty good idea of how much time 1 storypoint represents and will see it vary through time. Normally the time that 1 storypoint represents will decrease with the time of the project.

If you say that something will take y much hours, it doesn't vary in time and measurements will not be as accurate.

Also through my experience

  1. People make much more wrong measurements when they start throwing with hours.
  2. Managers try to put pressure on teams by making them measure with hours which has a counterproductive effect.

Lots of people put lots of thought into scrum as a new methodology which actually works really well, I wouldn't start changing it.

Matt Block replied on Mon, 2011/06/13 - 12:55pm

One benefit story points provides that this post ignores is the ability to see improvements in process and efficiency.  I think this is inline with what Jo was getting at...if you just use hours, how can you tell if you are getting any more efficient?  If you are doing good agile practices and making good use of your retrospective, you should be improving your process and increasing your velocity.  So you should really be seeing an increase in the number of story points per sprint that get completed.  As long as your story point scale is anchored well (so that a 2 now is the same as a 2 in a year) this is very useful information.  If you are just using hours you really can't see this improvement.  2 hours is 2 hours, but the tickets estimated as 2 hours last year may have been very simple tickets and now that we have improved our process we are doing much more complex tickets in 2 hours.  Even if you found a way to anchor that number, since it is based on time the conversation will get very confusing..."we estimated it as 2 weeks, that means we can get it done in an hour".

Sean Mchugh replied on Mon, 2011/06/13 - 5:58pm in response to: Josh Martin

In my experience, it's actually impossible to tell if three 13 point stories is realistic or not unless you have an intimate relationship with that team or understand their velocity. That being said, if you're using story points to determine how much work should go into a sprint (which is a time box) then you're estimating in time already, you've just changed the unit of measurement. An estimate is just that, an estimate which means that even estimating in time (vs points) takes risk and complexity into account.

Here's the other thing, I don't want to break each of my stories into tasks for my hours until I've committed to it since that takes effort and any item left outside of the sprint is potentially something that won't make it into the release and tasking it out would create wasted effort.

So if I were to estimate you're facebook login I would probably call it a 2 day feature (or story) and leave it at that. Will I take a full 2 days on it? Probably not but I know that there's some small amount of technical risk and at least three distinct things that need to be done. If everything goes exactly as planned then I might finish early or have a chance to dip back into the backlog but if I run into a problem (found a bug in the existing auth system, didn't see that coming) then I have some time to absorb it. Since nothing ever goes exactly as planned I end up with a pretty accurate estimate for the entire sprint.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers