Scene 1: Tragedy

We’re in a retrospective. This was after a major event, so we discussed a few of the things that have gone awry, like delayed integration with other teams, unfinished stories, and then how we’re going to fix them. All in all, a good open discussion.

And then, as we’re getting ready to close the session, one of the guys says the magic words: “But we didn’t discuss the real issue”.

Silence in the room.

What is the real issue, I ask.

“We’re way off on our estimates. ”

Why is that?

“We’re doing a lot of unplanned things. Production support, unplanned integration issues, running to lots of meetings. Then our planned tasks take longer. Our initial estimates don’t take that into account.”

Ok, I get that. Why is that a problem?

Silence in the room again. I think they are trying to find out what I’m missing. So I continue.

Why do you need estimates? 

“I need to give estimates about my work. The product owner needs them”.

What do you think we should do then, I ask, knowing what the answer would be.

“We need to work more on our estimates.”

Scene 2: Theory

Ok, makes sense, I say and turn to the product owner.

How do you, dear product owner, use these estimates?

“I use them to plan ahead. I know when things will be done, so I can communicate dates for other stake holders – customers, operations, and other interested parties”.

Ah, I say, but the team is struggling with delivery. In their own words, their estimates are way off. How can you plan like that?

“Well, I know that how the team works. I add buffers so the completion dates I communicate are more reliable.”

Interesting, I say, rubbing my chin slowly.

So the team give estimates that are used as a basis for planning, but are not used as-is. In fact, if the estimates given are more “accurate” the only effect will probably be smaller buffers added by the PO.

They look confused.

Scene 3: Reality

Before we solve the estimate issue, let’s look at how the work is done, I say. Are you working on the most important things?

They are thinking about it, and most of them nod “yes”, including the product owner. One developer says she’s not sure. While the main things she’s doing are important, lots of other interruptions may not be (but they are urgent). Others mumble in agreement.

That means we need to examine the work coming in, and make sure we work on the important things first.

Next question. When we work, are we doing this effectively?

An emphatic “No”.

“We’re working on too many things, some of tasks are blocked waiting for answers, and when switch tasks, or get back to them, there are context switches. Without the unplanned work, we’d work more effectively.”

Hmm, I say. So the actual work today takes longer because you’re not always working on the right things, and when you do you’re not doing those effectively.

“Yes”.

And obviously the estimates do not reflect the actual work.

“Yes”.

And you want the estimates to reflect the actual plan.

“Yes”.

So you’re interested in making the plan fit the work, rather than making the work effective. Are you solving the right problem?

Epilogue: The Real Issue

That would be a good point to stop, but you wouldn’t believe what happened next.

As the team discusses my last question, I see the guy who started this is not happy. I ask if the discussion makes sense, and I get a “yes, but…” look.

Before I get to probe more, he says “Everybody understands this reality. But when we miss our initial estimates, management still pressures us to finish the tasks according to them. If we’re wrong, and we usually are, that means staying long hours, and the disappointment by management.”

Now, THAT is an issue. And “more accurate” estimates will not solve it.

See, estimates are not useless, they are excellent in uncovering real problems.