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.

 

Facebooktwitterredditlinkedinmail

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

4 thoughts on “Do we Estimate in Scrum? Yes!

    1. Joe Little Post author

      Hi Chris,

      Good question. First, we are talking about estimates of effort. Not of business value. For now.
      Second, we expect any individual estimate to show some variability. We will always have variability.
      Third, we want and need the estimates in the aggregate to be useful and fairly accurate.
      The first level of aggregation is at the story level. The task estimates should equal the ‘story’ estimate. This is somewhat useful, especially in identifying estimating ‘mistakes’ we might learn from. So, we look for situations where one 2 SP story is 16 ideal hours and another 2 SP story is 32 hours. Maybe something is off.

      Next, and more importantly, we want the team to ‘commit’ to say 20 SP in a Sprint. (By commit we do NOT mean guarantee, but to have a high confidence in when they start.) And then, usually, hit 20 SP, ie, get all those 8 stories done that sprint. Done, done, as is often said.

      Now, if the Team does not get all the stories done, done in a given sprint, is the key root cause always ‘we are bad at estimating?’ I am guessing you have seen that be the main root cause, but I am also guessing that you have seen other, different main root causes. Which seems sensible to me.

      So, the Team has to make a fair judgment. In this case, what ‘weak estimating’ the main root cause?
      Usually they know, and usually it is fairly clear. One way or another.

      Does that help enough? I did not connect all the dots, but maybe you can from what I did say…
      Regards, Joe

      PS. Is estimating accurately, at any level, the most important thing? Of course not. Delivering value to customers is far more important. But still, customers do care about time.

  1. Mark Woollen

    Thank you Joe! This validates that we are experiencing evolution appropriately at “the client.” Interesting real world scenario… As we practice agile/scrum, we did not recognize (or realize) the potential velocity of the team until we encountered the unenviable position of impending delay. What happened? The “good stress” of sensing that a delay was imminent forced us into an exercise to more thoroughly assess the remaining work. We had to “prove” that the delay, renamed “extension”, was inevitable by estimating all of the remaining stories aligned with the next release.

    We learned lots going through this exercise under duress. We learned, as you’ve pointed out, the importance of estimating. We learned the importance of being diligent in the planning (categorization, prioritization and estimation) of our stories. We have a much better grasp of remaining effort, of team’s velocity, and higher confidence in our revised schedule!

    Let’s catch up soon!

    Reply
    1. Joe Little Post author

      Awesome.

      To me, the old POV of managers was: you aren’t going to change the schedule are you? Which put fear in the Team.

      The new POV should be: “Well, of course, as good knowledge workers you are learning and of course things are changing and the customer wants something somewhat different than what they said originally, so of course you have ‘changed’ the plans in this past sprint, right? So, what are the changes? And let’s see what we do about it.” An almost opposite attitude.

      The Team should have the attitude of the customer, that time is of the essence! And they should care about knowing, and getting more accurate about how to deliver the Minimum*** Marketable Feature Set. So, that we do re-planning every sprint as we learn and things change…that’s obvious. The only question is: how much time should we take to do that every sprint? This is not so clear. Except that NONE is clearly*** the wrong answer.

      Still, as you say, this is a common problem in the agile community. And good that your Team has recognized some things. And is changing. Of course, we all want to change ourselves more quickly! (Right now, I wish I could stop eating some wonderful brownies!!)

      Let me remind some people: One of the key reasons that Teams do not (re)estimate enough is that the environment does not reward them. In fact, often they are punished. For example, estimating is associated in their brains with punishments in the form of long long long hours. Or requests for doing the impossible in no time. (Crazy! Or at least, that is the way they hear it.) So un-doing this Pavlovian response (in the Scrum world) may take some time.
      Regards, Joe

Leave a Reply

Your email address will not be published. Required fields are marked *