Do we Estimate in Scrum? Yes!

A really smart and experienced colleague says we should not estimate.  Specifically: in Scrum we should not estimate.

Now, to get into the deep inner-workings of Lean and Continuous Flow…well, I am not going to go there today.

As a minor point, I will say the latest Scrum Guide to me, says we estimate in Scrum.  Especially ‘work remaining,’ both at a Sprint level, and at a ‘release’ level (although the Guide says ‘goal’ instead of release –)

Let’s assume we really need an explanation of why, not just ‘the bible says.’

Where do we start to explain?

I started at one place, and I kept going backwards. I kept asking myself “Yes, but why is that so?”  So, having gone backwards enough (at least, enough for me), I will go forward in ideas with you.

When the Duke basketball team plays UNC tonight, who is responsible for winning?  Just Mason Plumlee? (the big center for Duke, possibly their best player, a senior).  Coach K?  Well, they are …but the whole Team is responsible. They win or lose as a Team.  Coach K only says that 1 million times each season. They win or lose as a Team.

OK, in Scrum, who is responsible for success?  The Team.

We have this saying: The PO is the single wring-able neck. True, but possibly misleading. If the Team is not producing enough benefit over cost compared to other options (or just not enough period), then in Scrum, the PO has to call it and ‘stop the madness.’  Do the right thing. Stop the Team completely, or start on another product.

It does not mean that the PO is solely responsible for success.  All the members of the Team are still mutually responsible for success.

To customers, success always means delivering earlier, delivering fast. You, as a customer, want it yesterday.  It is a key component of success.

Now, customers understand it takes some time, and they say they want ‘everything.’  They need a solution now, so time is a critical factor.

So, we are always caught in this dilemma…do it faster AND give the customer more. It is a tension which will always exist.

There are lots of things we can do with this tension. Here are some classics:

• Death March!
• Unsustainable pace (the less immoral version)
• Cut the quality to make the date
• Give up
• Pretend like time is unimportant

Occasionally ‘give up’ is a responsible option, for example, when it is obvious our product will be too late to market.

Usually the responsible thing is for the whole Team to manage the tension.

In terms of specific trade-offs of stories (does it go in this release or the next release — is often the question), typically the PO makes the final call.  Based on all the input he or she can get.

But the Team is important too — for example, the Team does the real work and identifies its real impediments, which the SM drives to completion (one at a time).  So, all together they work on impediments, for example, to improve their velocity.  Thus, the Team also works hard to make the date.  (By hard, I do not mean more hours. I mean ‘with clear focus.’)   (I don’t want to mention any specific wonderful product that was late to market and failed.)

So, the whole Team needs estimates.

How much work will X be? (X could be a story or a whole release.)  And, as I assume you know, we use Story Points and Velocity in agile. (I won’t explain them here.)

So, what’s the problem?

Well, there are many problems to deal with. Some were mentioned above (Death March, for example).

Next problem.  Many, many Team members have seen estimates used, over and over again, to beat them into an unsustainable pace. They have been used irrationally and stupidly, so they often elicit an immediate visceral reaction. Please be considerate of them; the reaction is based on real (bad) experiences.  Not necessarily experiences at your company, but nonetheless real experiences for them.

Next problem. As soon as we do estimates, some stupid manager (yes, there are a few stupid managers out there) starts to think that the estimate is perfect.  It NEVER is. That’s why we call it an estimate, doh!  (Speaking to that manager right now.)

So, in Scrum we do lots of things to manage the estimates, manage the tension. Some are:

• Remove impediments to increase velocity
• Re-estimate later when we have better knowledge
• Learn more
• Break down the stories more, and move part of that work to later
• Try to harness the good change more (eg, learning, and … did we mention fixing impediments?)
• Don’t let the bad news get ‘better’ with age (one version: “no bug survives the sprint”)
• Learn to estimate better (tends to happen, to some degree, naturally with time)
• Estimate as a Team (gosh, to me it was assumed, but I guess I better make it explicit…this does help a lot, especially over time)

We also have to be careful what we say when. Example: In the initial release planning, we guess at the Team’s velocity. Should we tell a manager the initial date (with some buffer) immediately?

Maybe not!  Maybe wait a couple of sprints (this is how long the waterfall estimates used to take…it might be ok)…wait, find out the real velocity of the Team, and then propose a (more accurate usually) date range.

So, we need to use estimates in Scrum. In a professional way.

There is good stress and there is bad stress. Manage the tension in such a way that it becomes good stress for your Team. It won’t be easy, but then most good things require some work.

***

Was this convincing to you? Could you use these ideas to explain to the Team why they should want estimates?  Could this help your PO?

Comments please.

 

« « “If you wait for perfection, you might wait too long.” || Our Favorite Scrum Mistakes » »