How to estimate user stories

This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Askshutterstock_223123294

Ideal days

Ideal days are the most common way to estimate in traditional project management.  When estimating in ideal days, the assumption is “This is how long it would take if I had nothing else to work on.”

Ideal days are usually used in conjunction with some sort of “efficiency coefficient” whereby someone takes the ideal days and multiplies them by the number of actual ideal days you can get in a week.  For example, in 5 business days I get 3 ideal days of work done, so the coefficient is 3/5.  Therefore, if I estimate this work in ideal days and call it a 3, it will take me a week.

I’m not a big fan of using ideal days as an estimation method for a few reasons:Anytime you use calendar time for estimating, no matter the caveat, it tends to be used as a commitment.  Estimates != commitments, especially in complex-creative work.It creates a distracting vanity metric:  Getting ideal days to match calendar days (disguised as a quest for “efficiency”).  With this, instead of focusing on delivering value, the teams focus on “making the numbers match”

Story Points/Tshirt sizes

Story points are a way to decouple the estimation of size and effort from the duration of time.  Instead of trying to estimate how long something will take, you estimate how big it is and let your velocity data tell you how long it will take.

If you don’t have velocity data, take your best guess in terms of how much work a team can do in a sprint, then measure the actual when you have actual data.

I like story points as a sizing practice because once the teams get their minds around decoupling time and effort, it makes it easy to estimate large amounts of work quickly.

Be careful:  Its not a good practice to try to map story points to days directly.  The point of decoupling is to understand the change in the relationship between time and points, which changes as teams improve, add new members, get reconfigured, etc.

Threshold-based sizing

Another form of sizing I like to use is “Threshold-based sizing.”  This is where we set a threshold (say 3 days) and when we estimate, we are only interested in getting stories under the threshold.  This eliminates distractions around precision (2.3 days vs 2.8 days) and moves the stories toward a standard size.

For stories that are above the threshold, we split them, or decrease the scope, or cut functionality until they are below the threshold.

My preference is to use a combination of tshirt sizes and threshold estimation

At the release level, I like to use chunky tshirt sizes:  XL, XXL, XXXL

At the sprint level, I like to see smaller, more granular tshirt sizes:  S, M, L

When we go into sprint planning, I take the stories slated for that sprint and apply the threshold method, as a double check.  When applying the threshold, I use the rule of 1, 2, 3:

  • 1 user story should take
  • 2 people no more than
  • 3 days

Maybe its a developer and a tester, maybe its a front end developer and a back end developer, or maybe its 2 full stack developers.  The composition of the 2 people working on the deliverable doesn’t really matter to me.  What matters to me is that we are spreading knowledge around the team so we don’t end up in a situation where “Only on person knows about this..”

What are some other ways of estimation you have seen?

 

There was an issue loading your timed LeadBox™. Please check plugin settings.