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 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:
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.
Dave Wentzel CONTENT