D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Estimating Work Items by Hours–Idiotic You Say?

Monday, January 16, 2012 7:06 AM

An interesting discussion popped up on Twitter between myself, Steve Rogalsky, Terry Bunio, Mike Iwasiow, David Alpert, and some others around using hours as a software estimating unit of measure. Steve’s been reading the book Beyond the Goal by Eliyahu M. Goldratt and blogged about his stance on using hours for sizing work items.

In a nutshell Goldratt offers the following arguments:

Asking someone for a timeframe to complete a task puts their image in jeopardy

PMs will always try to squeeze whatever number you give.

Devs will fill the time in an estimate because if they don’t then they’ll be known as either exaggerators or as being very good but they don’t want to be held to a high level of expectation.

Estimating based on time will either waste hours to ensure estimates are met or will demoralize devs because they went over their estimate and this is totally “idiotic”.

So basically…

PMs are evil time crunchers who will squeeze every ounce of productivity out of developers on their projects

Developers are frail, timid creatures who have no personal guide on judgement or history of writing code that they can apply to task estimates

Developers must feel loved and accepted by their peers and that’s the most important thing.

image

As I’m learning more and more in my career, developing software is all about people and only partially about technology. I have no doubt that the Office Space-ish stereotypes Goldratt depicts exist – I’ve worked with some of them. But remember this all started with one question:

Is it really wrong to do hour-based estimating instead of story-point estimating?

In my view, storypoints are a buffer against reality. We feel better saying that something is a 3 instead of saying its 12 hours of effort – even though for reporting and tracking purposes, a 3 = 12 hours of effort. Also when starting out, most teams that use storypoints have to set baselines anyway else their estimating exercise makes no sense. So from the start, we’re masking hours behind a story point. So, speaking of idiotic…

Ok ok, don’t all pile on me for that last bit…was tongue in cheek (sort of). Here’s the funny thing – it doesn’t matter what unit of measure you estimate tasks in. What matters is the culture of the team, the shared commitment to success, the drive to delivery. Here’s what I try to implement on my teams that address some of Goldratt’s concerns.

Shared Estimating

The work items BAs provide need to be estimated, but I don’t want one person providing estimates. That act alone is wasteful for a few reasons. For one, that estimate is based on the sole experience and knowledge of that individual. A team is not made up of siloed individuals but a collection of people working together, people who have varied levels of experience, talent, and wisdom. It would be a detriment to a project *not* to do group estimating.

Technical Leadership

So you have a bunch of work items up on your Kanban board and there’s this one nasty grid that needs to do some nasty calculations. Your brand new, just graduated out of university, bright eyed and bushy tailed junior developer decides to take it! This is where sound technical leadership on a project (not technical, but personal) steps in to say “How about you tackle this task that will help you understand the new UI technology we’re using and the architecture stack?” Having the right people guiding the team is crucial, and that person should not be the PM – they have enough to deal with at the stakeholder level and you can’t assume PMs are technical.

Open and Honest Communication

I’ve heard so many stories from organizations that have a culture of fear. They can’t bubble up any concerns or bad news. Nobody wants to hear bad news, and nobody wants to be the bearer of it. What we need to do is remove that culture of fear from within the project. We need people to feel comfortable raising issues that come up so that as a team we can come up with a new solution, not point fingers in retribution. If you remove the fear, then raising issues isn’t a problem.

Create a Culture of Delivery

Goldratt’s argument is centered around an estimate for a specific task and whether the developer will complete it on time. In his view, the developer becomes entirely engrossed with how much time he’s spent, how much time is left, whether he’ll complete on time. But you can avoid that by creating a culture of delivery within your team, and these are basic Agile techniques. The easiest to implement is the use of short sprints and granular work items. Sure there’s more work items on the board, but if a developer completes 5 smaller work items within a sprint compared to 1 larger one, there is a psychological shift in perception – “I completed 5 things this sprint, I was very productive!”. Being productive feels good, and people want to feel good.

Moving work items from Work in Progress to Done should be seen as a big deal. On our team we applaud whenever we move items (we’ve toyed with the idea of getting a gong). Delivery is a good thing, it should be encouraged, and it should be celebrated!

So…is estimating based on hours bad?

WHO CARES?! If you don’t have the things I mentioned above, it doesn’t matter if you use story points, hours, days, parsecs, whatever – an arbitrary value assigned to a piece of work representing duration to complete is not what will determine success on your project. The people you staff it with, the way you lead them, and the culture you create around them will.




Feedback

# re: Estimating Work Items by Hours–Idiotic You Say?

Come to my estimation session at PrDC Calgary and I'll explain why estimating in hours isn't so great, and why not =). 1/16/2012 9:40 PM | Dylan Smith

# re: Estimating Work Items by Hours–Idiotic You Say?

You make some important points D'Arcy and I don't think anyone would argue that sharing, leadership, open communication and culture of delivery are important aspects of a successful team. My company lives and breathes this everyday and I can attest to the benefits first hand.

I haven't read enough about Goldratt's "Theory of Constraints" to fully understand his arguments but I do know that he is a respected authority on the topic and his methods are widely accepted and taught in hundreds of schools and companies. I can only assume he knows what he's talking about and it's unlikely that he would be so well respected if he actually went around saying all PMs are evil and all devs are frail. Just my take.

Regardless, estimation is a very complex topic and very important one as it's one of the primary communication mechanisms between business and IT. To say that Goldratt's theory is all bullsh't (lets cut to the chase) is a bit ignorant IMHO.

Also, your comments on Steve's blog calling him an "emotionless droid" for refusing to be drawn into a Jerry Springer session with you is a bit trashy, but maybe that's just me.

I have a tonne of respect for your work and contributions to the community... I was just surprised at how you tackled this discussion. That's all. 1/17/2012 10:17 AM | Mike Iwasiow

# re: Estimating Work Items by Hours–Idiotic You Say?

Dylan - Ha, nice plug!

Mike - It might have been that the text Steve posted was out of context with the surrounding chapter, but what was written on its own merit just came off as painting all PMs and Devs with a wide brush.

Also, Steve and I are really good friends and the droid bit was me poking fun at him - I guess without that context it does come off trollish, but that wasn't the intent. :) 1/17/2012 10:26 AM | D'Arcy from Winnipeg

# re: Estimating Work Items by Hours–Idiotic You Say?

Fair enough. Good discussion either way ;) 1/17/2012 11:53 AM | Mike Iwasiow

# re: Estimating Work Items by Hours–Idiotic You Say?

My response: http://bornagainagilist.wordpress.com/2012/01/22/estimation-story-points-hours-and-the-theory-of-constraints/
1/22/2012 5:49 PM | Terry Bunio

Post a comment