There was another interesting discussion on estimating and the use of Story Points versus Hours on Twitter between myself, Steve Rogalsky, D’Arcy Lussier, Mike Iwasiow, David Alpert, and a few others.
Steve quoted the book Beyond the Goal by Eliyahu M. Goldratt and blogged his opinion on using hours versus Story Points.
Suffice it to say, the opinions were widely varied and informative. I’ve made no secret of my opinion that although I use Story Points I also use hours for projects I am part of. But I this discussion enlightened me on some new ideas and concepts I was not aware of before. Before we start that discussion, I’d like to review what I believe the benefits are of Relative Estimating/Use of Story Points/Macro Estimating/Macro Tracking first. Lets just term the process Agile Estimating for brevity. 🙂
The Value of Agile Estimating
- Relative Estimating allows the estimating process to better leverage the human ability to estimate relatively instead of using absolute, discrete numbers.
- Use of Story Points allows for the estimates to be generated without internal biases as to what is a 1 day task, 2 day task, or a week task. This helps to make the Relative Estimates even more accurate.
- Macro estimating refers to the estimates being created by the entire group in a session that also collaboratively defines the requirements. Actually this type of group estimating and shared estimates has been around for almost 40 years and was initially termed Wideband-Delphi estimating. Mike Cohn popularized it in the Agile circles and made the process more collaborative, but it has remained essentially the same process.
- Macro Tracking refers to the progress of the project being tracked primarily through the project team’s iteration velocity. The tracking at a task level that is typically all the rage in a Work Breakdown Structure is not done. All tracking and subsequent planning is done through the use of the project’s iteration velocity.
I don’t believe anyone would argue against the four types of value listed above? I think all four of these types of value in the Agile Estimating practices return better estimates and better projects.
The vocal proponents of Story Points would also state that Story Points are required for both Macro Estimating and Macro Tracking. I would propose that this is incorrect, I can perform Macro Estimating and Macro Tracking using hours just as well as Story Points. If you don’t do Macro Estimating and Macro Tracking that isn’t the fault of the lack of Story Points, that is just bad project leadership.
Theory of Constraints
The book Beyond the Goal by Eliyahu M. Goldratt had proposed that estimating hours was local optimization. (I must admit I don’t fully understand the concept and must continue my reading on the Theory of Constraints)
a few of the quotes Steve had on his blog from Eliyahu M. Goldratt I believe illustrates that we are just talking about bad project leadership:
“The way to ensure that the project will finish on time is to ensure that every task will complete on time.”
This simply is an incorrect statement and illustrates a lack of macro thinking. Of course I can have a project complete on time without every task finishes on time. A project will be a continuum of tasks that finish early, on-time, and late. If you estimate and execute well, more time will be realized by tasks finishing early, than realized by those tasks finishing late.
“Suppose you are this person and you are asked how much time will this task take? You are extremely reluctant to give any number. And when you give that number the Project Manager will try to squeeze it. Why are you reluctant? Because you know that the number you give is an estimate but that it will be converted to a commitment – because the project needs to finish on time.”
This again illustrates bad project leadership where the Developer is the protagonist and is proposing estimates and the antagonist Project Manager is forcing the squeezing of the estimates and also converting them to task-based, or micro-level, commitments. Let’s be honest here, the problem is not that the estimates are made in hours. The problem is that the project leadership is wanting and the estimates are being tracked at far too low a level.
And finally…
“Due to the result that our local optimization turns any estimate into a commitment, we have developed the habit of giving estimates which includes in it the safety. If murphy (i.e. Murphy’s Law) doesn’t hit, we waste the time rather than giving it to the next link in the chain or project. If we do give it to the next link then we are declared as exaggerating and next time they won’t give us the extra time. So look what a horrible situation this is. And this… is what kills the project. This is totally idiotic”.”
I’m not sure calling something idiotic advances the discussion in any way, shape, or form. But maybe that is just me. 🙂 Seriously, I’m not sure beating the estimate on one task results in that excess time being wasted and not being applied to the next link in the chain or project? If you manage at the Macro level and one task comes in under, you realize that you have gained some buffer to offset future overages. If the sponsors of the projects view this assignment of extra time to the next link(task) as exaggerating, then the project leadership again has been found wanting. It is the project leadership’s responsibility to explain the reality of estimates. This again has nothing to do with estimates being in hours. Just good old-fashioned bad project leadership.
So do we enforce the abstraction of Story Points to address bad project leadership or just address the bad project leadership?
That said, I’d never recommend not using Story Points and Planning Poker sessions. Relative Estimating and Story Points are invaluable.
But to state that you can only do Macro Estimating and Macro Tracking on a project if you use Story Points is incorrect. I’ve converted Story Points to hours on many projects and been very successful.
And Finally….
The vast majority of us we need to find a way to work with hours as the number of clients and projects are not comfortable not having an estimate and schedule. Even if we all agree that estimating and estimating hours in particular causes problems, proposing to not estimate in hours is just not realistic. And you can get all the benefits of Agile Estimating using hours as well.
P.S. When we didn’t translate Story Points to hours, the developers I worked with did the translation themselves to ensure their progress was on track. When I’ve asked developers if they would like to also see the conversion to hours, they have all asked for it.
Agile PMO 