Mark Lawler in his post about story points, says he wants to “raise a glass of Champagne to toast the folks who came up with the concepts of ‘story points’.  You know that way of estimating work without actually saying anything useful or making any commitment to your business customers?”

I can certainly see how the whole idea of stories and story points can be confusing, especially to new teams and certainly to business customers.  But, I would like to offer a counterpoint and say story point estimation is a very useful, and efficient technique. 

Teams are asked to make a binding estimate, generally, at the beginning of a project, when they have the least amount of familiarity and information about a project.  Here is how Scott Adams illustrates this point through Dilbert:
 
 
Let’s look at what a story is.  A story is a bite-sized, digestible “requirement” that can be completed in a time-boxed interval.  It is stated from a perspective of a real user.  A story is just enough information written down and a promise between the product owner and the delivery team to have a future conversation about the rest.  Both the product owner and the team understand that there is some amount of uncertainty involved.  The product owner is not expected to know every detail of the story upfront, and the team doesn’t always know how they are going to produce that work.
The alternative used to be a detailed business requirements document or a product requirements document.  The PM and the business stakeholder then use these documents to obtain an estimate from the delivery team.  Or many times, engineering managers or leads arrive at these estimates, even though, they might not actually do this work themselves.  Teams are then held to this estimate, no matter what new information the team learns about themselves and about their project as it unfolds.
So how good are humans at estimating in absolute terms?  See if the following conversation sounds familiar to you:
An engineer’s significant other is preparing tacos for dinner.
Significant Other: How many tacos should I prepare for you, 3 or 4?
Propeller-head Engineer:  Well, let me see, I am a little hungry.
Significant Other: So 4?
Propeller-head Engineer:  I am not sure.  I had a smaller breakfast than usual.
Significant Other: So you are really hungry?  Make 5?
Propeller-head Engineer:  But, then I had this big lunch when I went out with my friends.
Significant Other: So then…3?
Propeller-head Engineer:  But, see I then went to the gym in the evening?
Exasperated Significant Other: So you’re hungry again?
Propeller-head engineer:  But, see my workout was really “light”.
Angry Significant Other: Then you are not that hungry?  Darn it, Propeller-head, will you just tell me how many tacos do you want to eat?
Propeller-head Engineer:  Tell me what kind of beans are you using?  Are you using sour cream, or guacamole?  How caloric is the salsa?
So when it comes to estimating and committing, we tend to over-analyze and take too much time to arrive at a precise answer.  On the other hand, we are actually good at comparing.  Back to the Significant Other and Propeller-head Engineer:
Significant Other: Damn it. Propeller-head, why do you always have to be so difficult?  Tell me, are you hungrier compare to last Friday, when we had tacos?
Propeller-head Engineer:  Yes I am.
Significant Other: You ate 3 tacos then.  How much hungrier are you compare to then?
Propeller-head Engineer:  I am little more hungrier than that, so let’s go with 4.
Bam, having a reference point helped speed things along (that or it must have been the wrath of the Significant Other)!  Estimating is relative sizing, so a team compares one story to others and arranges in generally like-sized groupings.  The story points are just a numeric values we assign to these piles.  Three considerations go into sizing a story:  effort, complexity and doubt.  So along with effort and complexity, uncertainty is built into these estimation.  What was the alternative in the past?  As other agilists have pointed out – the delivery teams were trained  in stating precise inaccuracies.  At the inception of a project, when the agile team and the business partners have the least amount of information for their projects, if we ask them to be prescient and produce accurate estimates; they will produce estimates, and precise ones, at that.  Just not accurate ones!
 
For example, I was just reminded, at a recent training, regarding the concept of accuracy and precision.  If I state that the value of Pi is 3.7909430, it is very precise, but it isn’t very accurate.  If I say 3, I am accurate, but not very precise.  When we are doing newer things, we are not always so good at them at first.  We, in the software business, to use an analogy, are more like chefs, and less like short-order cooks.  Chefs concoct new recipes, so it is hard in beginning to accurately and precisely figure out how long it will take to come up with a winning recipe.  A short order cook on the other hand, is handed a recipe and has a pretty good idea of how much time it will take to cook up the recipe.  Software engineers, if they are more familiar with their problem domain, can become more accurate as well as precise.
Picture a conversation between a PM and a delivery team:
PM: We need to produce an estimate to develop an integration with our business partner.
Delivery Team: Ok, do you have the integration specs? Do you have API Specs from the partner?
PM: No we don’t, but assume that we will communicate via FTP.
Delivery Team: And how many “functions” do you think we are going to need.
PM: Assume about 10 functions.
The delivery team talks amongst themselves.
A Dev Type: Let me look at our existing code for an hour – and I will tell you.  He returns two hours later.
Dev Type: Look, we already have done this type of work.  The existing sFTP protocol we  developed has about 15 functions, which took us about 6 weeks to develop and test,  So I think, we can turn this around in 2 weeks.
A test type:  And it will take me 2 weeks to test.
Delivery Team to the PM: We can do it in 4 weeks.
PM: Well guys, sorry to break this to you, but we need this within 3.5 weeks, otherwise, we will be off our critical path.
Two weeks later.
PM: Hi guys, the specs came in, our communication is via a web service.
A stunned Delivery Team: But, we haven’t done any web services development, and certainly not with this partner.  What’s more, the infrastructure folks alone are going to need a week to open up the firewall and communicate with our partners.
PM: I know guys, this is tough.  Oh and one other thing – since we got the specs a little later than expected, we will need you to get this done within next 3 weeks.  Sound good?  Thank you guys, you are the best team I have worked with.  I know you will come through.
 
The PM, in the above example shorten the duration, but did not take into consideration the effort involved.  This generally happens when stories are express in ideal days – effort or duration get enmeshed.  Or at least, effort gets overlooked.  in which case earth days, become just as arbitrary as story points.  Comparing one team’s estimate against another becomes just as problematic as with story points.
Extending Mark Lawler’s airlines example, if say you were giving an estimate of 30 minutes delay, both times.  But say, by two different airlines – Southwest Airlines and United Airlines, which one would you trust?  Most people would probably pick Southwest as they have a stellar on-time record.  With United, who knows?  Unit of measurement is still hours, but Southwest and United Airlines estimates aren’t comparable as United doesn’t have a comparable on-time record.
 
With story point, if our customers have another key piece of data – the team’s velocity, they can also start getting better predictability.  Even when plans change, which we know, they inevitably, do.  Let’s say for example, an agile team estimates its release backlog contains stories worth 100 story points.  After sprinting for 3 sprints, they establish their average rolling velocity to be 10 story points per sprint.  Now based on this, the product owner will know that it will take another 7 sprints to exhaust the backlog (70 remaining points).  But, let’s say if the product owner estimates her “must have” story cut line is at 60 points.  She can now see that her team can achieve this with 3 more sprints (30 story points achieved and 30 more expected).  If she thinks of adding 5 more story points of “must have” scope.  She can also predict that it will take 4 more sprints (65 total must have story points).  Or say, if she wants to de-scope 10 must have story points, she can predict that the team can deliver this in 2 more sprints (20 remaining must have points).  What’s more, she doesn’t need to go back and worry about the fact that Ralph is taking a 3-week vacation or that Sally has a series of 2-hours doctor’s appointment.
 
Credit Clark and Vizdos
 
Story points, combined with team velocity, can produce fairly accurate estimates, faster.  In order to get better at estimating, more often than not, the contributing factors are that a delivery team stays constant, understands their problem domain, establishes a rhythm, and constantly inspects and adapts.  They can get better at estimation, irrespective of whether they use points, “gummy bears”, earth or martian days!  But, estimating in story points, has an advantage of not spending a whole lot of time in arriving at precise but inaccurate estimates, and avoid the trap of confusing effort and duration when contrasted with estimating in days.
 
And one last thing, just the other day, the cable guy promised he’ll be there to repair cable service, some time between 8-12pm (not very precise) and showed up at 130pm (not very accurate, either)!
Advertisements