Estimation, Story Points, Hours, and the Theory of Constraints

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

  1. Relative Estimating allows the estimating process to better leverage the human ability to estimate relatively instead of using absolute, discrete numbers.
  2. 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.
  3. 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.
  4. 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.






Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

7 thoughts on “Estimation, Story Points, Hours, and the Theory of Constraints”

  1. Thanks Terry – I responded to you back in the original post. I didn’t expect this topic to be so ‘hot’, but it is kind of fun… Essentially, we have this:
    1) Yes that story has elements of bad management and leadership, but it is also a story of a person who wishes to be reliable and how hourly estimates for tasks/stories can negatively affect the outcome of your project because of that desire.
    2) I question your last statement about hours being as beneficial as points. Hours are different per person based on skill & experience, points are not.


  2. I think the Story points stuff is just silliness posing as utility.

    It’s main function in life (to me) is to avoid direct comparisons between your old (non agile) method and your new (agile) method.

    Since hours would be comparable to hours, and story points are not, they go with the story points.

    Also it’s easy to fudge the story point #s to achieve higher velocity.

    One can simply estimate every task that was 1 point to 2 points, and now velocity has doubled!

    With hours this charade would be too visible for comfort.



  3. Thanks for the reply Steve. You highlight a very good point that is commonly discussed; that hours are different per person based upon skill and experience where Story Points are not. I think this is incorrect. Why? Because of what we are measuring, not the unit of measurement.
    People state that Story Points do not differ between developers only because they track iteration velocity not individual velocity. (And I would never recommend tracking individual velocity. Again bad Leadership) If I have two equivalent stories with the same Story Points and one is assigned to a technical lead and one a foundation developer, the technical lead will usually complete his story much sooner. This is not bad, just reality. But the iteration velocity doesn’t differ because we are measuring at the iteration level. Why do people think hours are more variable than Story Points? Because sometimes with bad leadership we track them at the individual and task level. If we track hours at the iteration level and understand that meeting every task estimate isn’t the goal, but maintaining a steady iteration hourly velocity is…

    I agree with point 1, but I think User Story Points and Hours can be used interchangeably after the initial planning is done and we gain the benefit of Relative Estimating with the bias of time estimates. It isn’t the unit of measurement (Story Points versus Hours) that provide the benefit but rather the granularity. (Iteration versus individual or task)



  4. The reading of “Critical Chain”, another book of Elihyahu Goldratt dedicated to his ideas on project management, could help you to understand the Theory of Constraints original contribution to this matter.


  5. Another recommendation for Critical Chain. It is specifically focused on project management and the question of why it always takes so long and costs so much to develop new products. He goes into the problems with estimates much more clearly in the book.


    1. Thanks Steve. I will definitely have to pick it up. Steve, is the book equally applicable to Project Management as well and Product Management?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: