Agile, Agile Estimating, Project Management

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.

 

 

 

 

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

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.

    Posted by Steve Rogalsky | January 23, 2012, 3:21 am
  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.

    Jordan

    Posted by Jordan | January 23, 2012, 5:30 am
  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)

    Thoughts?

    Posted by bornagainagilist | January 24, 2012, 7:06 pm
  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.

    Posted by Joel-Henry GROSSARD | January 28, 2012, 8:53 am
  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.

    Posted by Steve Holt | January 31, 2012, 7:20 am

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: