On Points

Software estimation "points" were never meant to be applied universally in scrum and agile.  They were meant to help dysfunctional teams meet "goals."  Points solve the wrong problems, and solve them in a way that fosters distrust with management and customers.  There are better alternatives.  

Scrum story points.  I hate 'em.  This post is me complaining about points and their relationship to dysfunctional teams that can't deliver value with their development efforts given a set of deadlines.  I've written about points previously in "[[The Cargo Cults of Software Development Management]]" and "Metrics That Count (and it ain't points). "

Point History

If you do software development in an agile/scrum shop (and who isn't?) then you are probably aware of what a "point" is.  Otherwise, here's the history.  Back in the day we estimated how long it would take to deliver a product using a metric called "time".  Sometimes we were more accurate and called our estimates "man-hours" or "man-months".  Project managers called it "effort".  A developer would say, "Mr. Project Manager, I estimate that it will take me 40 hours to complete this task."  Immediately an experienced developer would see some problems with this:  

• 40 hours does not mean, "I'll have it done in 5 eight-hour days".  The fact is, given an 8 hour work day the average developer only spends 3.2 hours, on average, doing project task work.  (I just made that statistic up, but it sounds reasonable to me).  The other 4.8 hours is spent doing these things...in order:
  • coffee break
  • morning meeting
  • coffee break
  • answering emails
  • bathroom break (due to excessive coffee consumption)
  • water cooler gossip/coffee break
  • mentoring/code reviews
  • working on prod crises
  • coffee break
  • responding to voicemails and IMs
  • finally, working on the project task
  • daily walk around the parking lot
  • Go home and relax.  That was such a busy typical day that there wasn't even time for lunch!  (btw, if you are a smoker, add a few of those breaks above).  
• A task may take 40 hours if the hours are contiguous.  But if that 40 hour task gets split over a month then there needs to be time factored in for "ramp-down" and "ramp-up" (context switching).  BTW, this is why Kanban religiously believes in WIP Limits.  "Stop Starting and Start Finishing".  The less time spent context switching the more time can be allocated to productive project work.  
• A task may be estimated to take 40 hours on Monday but may be completed by Tuesday afternoon.  This happens when the task is easily divisible to multiple resources who begin work immediately.  

The above bullet points should be common sense, unfortunately they are not.  Because of that managers hear "40 hours" and assume "next week".  This makes the project team look less-than-productive to management.  Even in the case where we "divide and conquer" and are done ahead of schedule it still looks to management like we can't estimate well.  

Mathematical Time vs Real Time is Confusing to the Human Mind

So the real problem was how to make management understand that "time estimates" were really "duration effort estimates" vs "we'll have this work done by the following date" estimates.  Metaphysicists call this mathematical time (measurable duration) vs real time (continuous and indivisible).  The two concepts are easily confused by the mind.  This is why kids often say, "remember when we had that bad blizzard last week?"...in the middle of August.  It takes time for a child's intellect to grasp real time and measure it accurately.   The problem is that "time" means two different things.  It can be a point-in-time or a measurement-of-time.  The same term means two different things.  Damn English language!

When a word means two different things the easiest way to avoid confusing things is to stop using the word in one instance entirely.  

So "points" were invented as a way to express mathematical time (duration) without confusion.  Initially a point might have been 8 hours of work, although the conversion to mathematical time units varies by team (more on this below).  Points are, generally, expressed as a Fibonacci sequence.  There is "1 point of effort", "2 points of effort", 3, 5, 8, and 13 points of effort, etc.  So, roughly if a point is 8 hours of work then a 5 point story would take a week.  We use Fibonacci numbers to indicate that larger tasks/stories will take longer amounts of time and generally no one can estimate things accurately when the time components gets large.  Hence, the gaps increase just like a Fibonacci sequence.  Note that this means longer durations are harder to predict accurately in real time...just like a child can't accurately predict in August that the "bad blizzard" didn't occur "last week".  

Back to the History Lesson

But points used in the fashion above, with a direct conversion to a duration, are meaningless.  If you say that 1 point = 8 hours then some simple math gets us back in the problem of deriving "real time" from "mathematical time".  And again, we know that we can't seem to keep these commitments due to the other constraints on our time (see the bulleted list above, again).  So points were supposed to be purposely nebulous.  The conversion factor (1 point = 8 hours) was meant to be a closely guarded secret that management was never supposed to know.  I've worked at places where there were signs on the walls that FORBID anyone from equating a point to a time unit.  You could equate a point to a doughnut, but not to time (I never understood that analogy).  The idea was to keep the time estimates purposefully vague for management.  BTW, those shops NEVER delivered working software by their deadline.  More on this, too, later. 

Managers and Sales Guys hated points almost from the start.  They viewed points as a way to obfuscate the planning process and as a way to make excuses for missed deadlines ("Yeah, we didn't deliver working software by your deadline, but we completed 120% of our assigned points.").  Really smart managers can easily circumvent this "point nonsense" by simply asking, "OK, you are telling me that this task is a 5 pointer, when will it be done?"  How does the scrum team ANSWER that question?  (Hint...it can't be done using points).  

Further, it didn't take long for teams to "game the point system".  I've worked on teams where EVERY sprint contained certain buffer "stories" that were given points.  These buffer stories were used in case the team (or an individual) couldn't make the sprint point goal.  These stories really had very little "actual" work that had any kind of business value.  They were merely closed out near the end of the sprint to "claim the points" so the team met their goals.  On a sprint burndown chart you could spot these quickly by looking for a radical increase in productivity in the last few days of the sprint.  That productivity improvement was the "fake points" being claimed.  Granted, most people finish up their tasks during that last push, but if you saw tasks closed out called , "Update the configuration and documentation for the NR281 system", and you never heard of NR281, then you might have a fake buffer task.  

Points have Solved the Wrong Problem

So points were invented to solve these issues:

• To stop the "real time" vs "mathematical time" confusion...duration vs deadlines.  
• To delineate to management the time spent on project work vs non-project work (sundry duties in the bulleted list above that we all fail to take into our time estimates)
• To help dysfunctional teams meet "goals" and appear functional.

To be clear, points were NEVER meant to be used universally within agile or scrum.  (See the above link for proof).  

But let's think back to what the real problem was...estimation of effort.  Points are purposefully meant to confuse and obfuscate a perfectly rational and valid need...how much effort is required to deliver X to our customer?  As technologists we should not work at cross-purposes with management, shareholders, and our customers.  Yet that is exactly what points do.  

Points don't foster trust

As I mentioned in my last post, [[The #NoEstimates Movement is Nuts]], management and entrepreneurs require estimates to determine, minimally, if the Expected Monetary Value (EMV) of a project makes it a profitable investment.  Points, based on what I've mentioned above, are a method by development teams to obfuscate that process.  I've sat in so many meetings with project stakeholders over the years where they were visibly disgusted with the point system and the fact that they could not get a simple answer to the question, "how long will this take?"  

Points aren't the only obfuscation tool that business folks hate.  T-shirt size estimation is another one, which is really just a "second derivative obfuscation"...it's meant to be even less accurate than point estimation.  At least with the point system a stakeholder can do some rudimentary math to get a duration estimate.  

I've written previous that in software development, points don't matter, only shipped software.  That's all your customers care about, that's all your project sponsor cares about, and it's all you should care about.  

Do Points hold any value?

Sure, for a team to use internally to understand relative estimation.  "We have to give an estimate for Project Widget.  We just finished Project FooBar which should be about half the effort of Project Widget.  Let's look back and see how long Widget took us to develop and we'll use half of that as our estimate."

But those relative estimations should be kept internal to the team.  You really shouldn't give management or your customer a "point effort" when what they really want to know is when they are going to get their finished product.  

Estimation is Hard

Estimation is a struggle for everyone.  Your mechanic can't estimate how much it will cost to fix your car and your programmer can't estimate how long it will take to roll out a feature.  

Is there an alternative that will get us the goal of accurate work effort estimations without points?  I think so.  Here's how I do it:  

• Always understand what the Minimum Marketable Feature or Minimum Viable Product is for your task.  The Sales Guy may want all kinds of bells and whistles.  Press him to note whether each one is an MVP or not.  
• Break the work down into the smallest possible tasks and put duration estimates on those.  
• Determine how much of an 8 hour day is spent doing "sundry duties" (the non-project work you do...see the list above)...then add a contingency.  You should be trying to refine this number to be more accurate every sprint.  And this number may be different for every team member, depending on various factors.  
• Add some additional buffer reserve.  
• If you find you are not meeting your estimate determine if there are things that you are doing that are not part of the MVP and stop doing them.  For instance, not all code needs to be perfect with total unit test code coverage.  (Very controversial, I know).  Don't fear technical debt. 
• Always perform post-mortems on your estimates after your project completes.  Was your estimate accurate?  What contributed to inaccuracies?  Use those "lessons learned" to help you understand the cognitive reasons why you can't accurately estimate.  

Final Thoughts

Imagine you were building a new home and were talking to your general contractor.  He gives you a proposal regarding how much the house will talk.  You both negotiate a few features to get the cost in-line with your budget.  The GC mentions to you that any change to the final contract will need to have a change order that will lay out the costs of the change and how the change will affect deadlines.  You finally reach agreement and you ask, "so, when can I move into my new house?"  

Would you accept an answer of, "Well, I estimate this home is a ten pointer based on previous projects I've worked on."  

That's clearly not going to work.  You expert your GC to give you a definite date and your contract will specify what penalties are imposed if the delivery dates are missed.  

If you think I'm nuts then you'll LOVE this article:  There's No Room for Deadlines

You have just read "[[On Points]]" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.