#NoEstimates Does Not Stop Agile Metric Abuse

The #NoEstimates crowd wants the agile community to stop estimating stories on scrum projects. Their reasoning:  story points and velocity calculations are gamed and abused.

Christina Welsh | Metric | Flickr

Christina Welsh | Metric | Flickr

And they are right. Management teams, scrum masters, and product owners abuse these numbers…often. But getting rid of agile estimation and a scrum team’s velocity calculations is not the solution.

In fact, you lose quite a few benefits that estimation brings to the scrum team:

  • The conversations that arise from planning poker tends to smoke out hidden issues and drives whole team learning about the story being estimated.
  • A groomed and estimated product backlog gives a transparent view in to the work that the team is getting “done”.
  • The Product Owner has the ability to forecast product releases based on the velocity of the team – driven by the estimates.
  • The development team can use velocity and other agile metrics to drive continuous improvement and to help gauge what their sustainable pace is over time.

The benefits of the agile estimation process leads me to think the #NoEstimates group is chasing the wrong problem. Let’s looks at the reasons to ditch estimating story points and calculating velocity given by some of the more visible proponents of #NoEstimates practices:

The charge filed against estimations and velocity are not new. I’ve covered the abuses of velocity and the gaming of estimations in past posts. Where I disagree with the #NoEstimations group is that the abuses are the fault of the metrics themselves. Estimates and velocity are just numbers.

The problem is the conflict between traditional management and agile teams.

In his recent blog post – Agile Coaches – We’re coaching the wrong people!?!?Bob Galen cuts to the heart of the matter:

Instead of taking the easy road (and money) by mostly training & coaching teams, I’d like us to focus on partnering with and training the management tiers within organizations. In fact, I’m starting to think we’ve been avoiding these folks.

Picture a newly minted scrum master, the ink on their certification not even dry yet, marching in to a meeting with traditional managers and trying to explain how velocity is a team metric, not a management tool.

The scrum master doesn’t stand a chance.

Clearly, management are the very people that need to have a solid understanding of agile principles, practices and values if any meaningful organizational change is going to take place. And we have not helped them get there.

Mr. Galen touches on this as well.

As I reflect on my most successful coaching gigs, these ratios come through—in coaching, conversations, training, and simply influencing change. The middle management tier in organizations, comprised of team leads, managers, and directors, needs the most help in making the transition. And they’re in the position to do the most with the coaching, helping to sustain and grow it.

#CoachingUp is the better way to solve the abuses that the #NoEstimates fans use to justify their movement. Simply deciding to not provide estimates adds to the already widening gap between traditional management and agile software development teams.

As agile practitioners, we should work with our management teams at all levels to get them the knowledge and information that they need to trust us to deliver our work. Otherwise, it does not matter how you decide to slice your stories. Points or not points, they will still seek traditional ways to manage our agile teams.

Question: It’s your turn! Do you think it’s time to stop using story points? Have you seen situations where #CoachingUp helped? You can leave a comment by clicking here.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • Pingback: 005 – Agile for HumansAgile Answer Man | Agile Answer Man()

  • Pingback: The Product Owner Says #NoEstimates From the Team. Now what? | Agile Answer Man | Scrum Lean Kanban | by Ryan Ripley()

  • I hadn’t heard of #NoEstimates movement until I heard Lee Brandt give a presentation at the Iowa Code Camp. Although it sounds good I do agree with your benefits that you point out Ryan. Good work!

    • Thanks Tom, I appreciate the feedback. #NoEstimates is an interesting topic. I’m going to continue to write about it and see where my thoughts land. This is the best part of agile, we get to inspect and adapt our thinking constantly! Best wishes and thanks again for visiting.

  • Neil Killick

    Good article. Let me clear a few things up though, at least from my POV.

    1. I do not “want the agile community to stop estimating stories on scrum projects”. I have explicitly recommended that teams do not simply stop estimating, just because of the #NoEstimates buzz. My message is that teams should decide how much work they take on in a sprint and not be asked to do any further deterministic estimation of “how long this will take”. If the PO needs to make forecasts beyond the sprint about release dates, or how much might get done by a particular date, they should use probabilistic forecasting techniques, not ask the team. All of this is as per scrum guide. Then, IMO, the PO should use this information to inform *prioritisation* decisions, NOT go/no-go decisions. “Shit, this feature might not get done if I leave it at number 10 in the backlog, so I’d better move it up”. This is good project management. Good risk reduction. #NoEstimates is about making informed decisions, and I don’t believe asking the team how long something will take is the best way of getting the right information. Effort estimates do not account for lead time factors such as position in queue, priority changes and other delays. Even if they did, they will likely be wrong, so we should not place so much credence in them.

    2. Story points and velocity being gamed are not “the reason” for #NoEstimates. They are one of many dysfunctions around estimation culture, but actually even when story points are used in healthy ways I still think it is better to use queuing theory, empiricism and better project management than asking people “how long”.

    3. The “conversations that arise from planning poker” are not a benefit of estimating. They are a benefit of collaborating as a team around a potential piece of work. In fact, planning poker conflates estimation and conversation in unproductive ways. For example, quicker consensus on estimates come out of silent collaboration. Better planning certainly does not. I advocate “story slicing” sessions instead of planning poker, with explicit policies on when to stop slicing (i.e. my “slicing heuristic”, contributing to the “definition of ready”).

    4. You can provide transparency into progress by using cycle/lead times to show wait times in the queue/backlog without having to estimate every single thing. In fact, the transparency is better with this approach. You can’t quickly derive a wait time from a backlog estimated in story points. Even if you line up put PBI’s into the next few sprints (which is completely not scrum, but anyway), as soon as you want to change the priority of cards you end up with a headache of updating everything in order to keep the same transparency of being able to look at any card and say “this is how long we have to wait for that”.

    5. Story point velocity is not required for the team to continuously improve and find their sustainable pace. Cycle/lead times are better metrics to try and improve because they directly impact the customer (wait time). Even if you don’t game anything, increasing velocity does not necessarily reduce wait times for the customer. Proper prioritisation, an understanding of queues, good story slicing, good technical practices (quality, maintainability, agility) and a focus on value are more customer-centric areas on which to focus.

    I agree with most of the other stuff 🙂

    • #1 – I completely agree with you 🙂

      #2 – The consistent argument, across many blogs and articles, is that the abuse of estimates and velocity is the key reason to look at #NoEstimates. That is the basis of my comment. As for asking teams “how long?” I agree with you. Teams should answer the effort/size question for their own edification and internal measurements. Nothing external of the team should be driven by the estimate that occur during planning poker.

      #3 – The estimating process does drive the conversation. And again your argument is based on stopping bad behavior “For example, quicker consensus on estimates come out of silent collaboration.” Why not coach out the bad behavior instead of abandoning the practice?

      “I advocate “story slicing” sessions instead of planning poker, with explicit policies on when to stop slicing”

      This is still an exercise in estimation. When you set a fixed sizing for a story that you are trying to slice to you’ve set a target. The team then continually estimates the size of their work until they hit that target. It’s the only way to measure if/when they hit the criteria that’s been set.

      #4 – Why is a change in the priority of a PBI on a product backlog a headache? Teams should be re-estimating and grooming/refining their backlogs regularly. The estimating process (planning poker, affinity estimation, t-shirt sizing, etc) is low ceremony to prevent headaches.

      I also think that you’ve perhaps traded “not having to estimate every single thing” for “having to slice every single story down to a fixed measurement”. That slicing effort isn’t free either and it is what makes the transparency part of a cycle/lead time based estimation scheme work…Doesn’t this overhead impact your cycle/lead times? The customer is not getting value from this.

      #5 – Story point velocity can help a team continuously improve and find their sustainable pace though…Are you optimizing to “wait time”? Why not optimize towards value? I think you’re also underplaying the usefulness of knowing the amount of effort a team can deliver in a sprint. I’ve worked directly with PO’s who value that measurement quite a bit when forecasting a release plan. Of course, your other observations are spot on.
      The point that stands out to me is that in either scheme the team is still estimating the size of their work. So what is gained by adding the overhead of slicing stories to an artificial size? In my opinion, not much. I’d rather focus my efforts on CoachingUp to management and removing the bad behaviors that cause pain for the team. To me this is the root of the problem.

      Neil, thanks for posting your thoughts. I enjoy your blog and am grateful that you decided to spend some time on mine. I hope we can continue this discussion. The topic is fascinating and does get people thinking about the practices that we often take for granted. 🙂

      • Neil Killick

        #2. Like I said it’s definitely one of the problems, but not *the* problem, AFAIK.

        #3. If you have an estimation session, you will likely have conversations about the work. This is not the same as “estimation sessions drive conversations”. There are other ways of discussing upcoming work to gain shared understanding. My argument is there are better ways 🙂

        Please read more about my slicing heuristic idea because you’ve misrepresented it. You don’t slice work until it is a certain *size*. You slice it until it has reached some criteria agreed by the team. You measure size *after* the fact using e.g. sticky dots on cards and control charts, and then inspect and adapt your heuristic accordingly. An example might be “Story must not have more than 1 acceptance criterion” or “Story must not have more than 6 tasks”.

        #4. Imagine a backlog of 10 stories on a wall, in priority order, all with a story point estimate on them. In order for PO to ascertain when story 10 might be delivered, they must add up all the story points and then look at average velocity. Now, if they swap out a couple of cards for new cards of different size, story 10’s wait time might have changed. Now imagine the same scenario for a backlog of 20, 50, 100 cards. Every time something new appears, or the order changes, the PO cannot make a quick observation of potential wait time. It’s way, way easier if you are using card counting and queuing theory to ascertain wait times.

        Slicing is not done on the entire backlog. It is only done JIT at the appropriate level of granularity, e.g. slice themes to features at release planning, features to stories in grooming/sprint planning. This is absolutely fine due to law of large numbers, averages, queues and YAGNI. Card counting is as good as, if not better, predictor than story points, and regardless if we are iterating we are not looking to deliver the entire backlog anyway.

        #5. Good teams optimise for value continuously, agreed. I am not underplaying the usefulness of velocity for release planning. If you want to plan releases with forecasts in this way (which I think is a flawed approach, but anyway…) then you’re just as well off, or better off, forecasting using counting cards and Little’s Law. If you’re WIP (count and size) is all over the place then velocity will be too. If it’s not, just count cards!
        And, like I said, I agree that “coaching up” is the thing to focus on. If the team is happy and effective with what they are doing then great!

        • #2 – What is *the* problem you are trying to solve with #NoEstimates?

          #3 – “You slice it until it has reached some criteria agreed by the team. You measure size *after* the fact using e.g. sticky dots on cards and control charts, and then inspect and adapt your heuristic accordingly.”

          How isn’t this another form of estimating? I use story points, you use sticky dots and heuristics to guide you. You’re still estimating.

          #4 – “Slicing is not done on the entire backlog. It is only done JIT at the appropriate level of granularity, e.g. slice themes to features at release planning, features to stories in grooming/sprint planning.”

          So is story point estimation. We only look a few sprints out as stories past that point are less understood and are typically epics. We do the same process that you described. Decomposition and slicing exist on both sides.

          “Card counting is as good as, if not better, predictor than story points, and regardless if we are iterating we are not looking to deliver the entire backlog anyway.”

          Both ways “work” though. I fully support teams trying each way to see which makes them more productive. It’s honestly up to the team anyways, they own their estimates and the estimation process. A scrum team that uses story points is also not looking to deliver the entire backlog. The party line is that many scrum projects (story point based) stop at 60% of a backlog due to the diminishing value of the stories being delivered.

          #5 – How is it better?

          Thanks for the replies. I appreciate the amount of time you’ve spent on this discussion. Lot’s of great back and forth here!


  • Joshua Kerievsky

    Release Planning & Agile Chartering are two of the many ways we “manage up.” Iterative Release Planning does an awesome job of informing management about our progress without relying on story points or velocity calculations. I describe Iterative Release Planning at the tail end of the Stop Using Story Points points. The bottom line is that velocity calculations and story points are not needed for producing valuable, high-quality software and giving management ever-more-accurate updates about the progress to produce such software.

    • Josh, I’m not sure that we are too far apart. I think that we can accomplish the same benefits of Iterative Release Planning in an environment that uses story points and velocity.
      If the team decides on a 2 weeks sprint and that a story that is sized at X story points is the biggest story it can deliver then we can perform the same process that you outlined in your post. This team can also (and should) re-estimate regularly for the benefits you mentioned.
      In both instances an upper limit on size is set (in your case it’s 2 weeks) and the team does the story mapping that you described going forward. Evolutionary design, re-scoping, re-thinking, and re-planning all fit in to this scheme as well.
      Great thoughts and thank you for commenting! I appreciate you jumping in and sharing your thoughts on the blog.