Skip to main content

bad agile estimation

Depending on how you define the term, I have been on at least five and as many as seven agile software teams. Two were brilliant; two were poisonous; the rest were just flaky. A big part of the poison stems from not understanding how to do agile estimation.

This is part of a message that showed up on a mail list I lurk on:

I'm working with a team that does great work. They are skilled and
work well together.

They also average about 50% or less in meeting their sprint
commitments. And don't seem to mind.

"There's a lot to do we just didn't get to it all."
"We'll do that in the next sprint."
"Yeah, that's not working yet."

These are the kinds of statements during the sprint or in the retrospectives.

How do I help this team look at the problem to solve it, instead of
just living with it?

Since the list name has the word "Scrum" in it, I will assume this person is a Scrum Master.

The first misunderstanding here is to know that all estimations are wrong. But when we do estimation in an agile way, we find over time that as we come to share a consistent idea of what a "point" means, that our estimations will be consistently wrong in the same way. This allows us to plan with a high degree of accuracy.

So if you have a agile team that consistently estimates 20 points per sprint and achieves 10 points per sprint, then the capacity of the team is 10 points, and 10 points is the figure you need to use for planning purposes.

The term "meeting their sprint commitments" bothers me a lot. For one thing, insisting that a team complete more stories than the capacity of the team can support is a well-known recipe for technical debt and poor quality. For another thing, it's not "their" sprint commitments, it is our sprint commitments. Finally, I object to describing this situation as "a problem" for the team to look at.

Remember what the job of the Scrum Master is? The Scrum Master has only one job on the team: to remove impediments. If there is a business reason to achieve a consistent velocity of 15 points instead of 10 points, then the Scrum Master should examine the situation for impediments to remove, not try to force the team to meet some sort of imaginary capacity in order to satisfy the requirements of what is essentially an old-style Gantt chart.


TestyRedhead said…
Wow. I was accused of not meeting my commitments in a sprint. If you looked deeper into why, we had a system we rely on which took a huge change causing 3 serious bugs. It broke our sanity test. It wiped out our test data. I worked weekends and nights trying to solve it.

Is there a team member who isn't honestly trying to fulfill their role? If so, deal with that. It is frustrating to me when setting arbitrary goals becomes more important than providing value.

It appears that metrics abuse can happen no matter how few you have, no matter how much change you take to try to avoid it.

Seems to me you're reading a lot into the post that isn't necessarily there. (I haven't read the original thread, so maybe there's more info you have that I don't.)

The situation as described by the poster: Every couple weeks the team says, "we're going to complete X." A couple weeks later they complete something less. They treat this situation as normal.

Maybe there's some outside push for a higher commitment than Yesterday's Weather would say is realistic. This seems to be what you assume is going on, but I don't see evidence for it in the excerpt you shared.

For a moment, let's assume the ScrumMaster is not pushing an unrealistic commitment, but rather supports the team in whatever commitment they make. Then, we have a team that routinely overcommits on their own. This looks like a problem to me. Not necessarily a problem of underdelivery, but a problem of mismatch between what the team thinks it can do and what it actually does. I think it's worth digging into why. Why does the team think they'll complete more in *this* sprint than the last one? What gets in the way to keep the team from accomplishing what they think they can accomplish? Are there hidden impediments the ScrumMaster could help resolve?

As you say, the ScrumMaster is there to remove impediments. Maybe this routine overcommitment is a symptom of impediments that wouldn't be revealed without an honest conversation about "the problem."

The way we use the word "commitment" in Scrum bothers me, too. It doesn't fit the common use of the word and leads to misunderstandings like this one. But I haven't found a better alternative yet.

I've seen plenty of cases of agile estimation misunderstood and misused. I just don't necessarily see one here.

Alex said…
It's important to note that if your team is consistently not keeping commitments, it may not just be because of poor estimation. It could be, perhaps, that the customer keeps requesting changes in mid-sprint and the team keeps allowing that.

The idea of keeping the commitment, and truly reviewing why it wasn't met, allows Scrum to expose problems - that's what Scrum process is supposed to do. If you simply chalk it up to bad estimation, you could be allowing real problems to exist without shining a light on them.
Lisa said…
This is why our team long ago pushed back on the idea of "committing" to a certain amount of work each sprint. It didn't make us work harder - we already work as hard as we can and still deliver quality. It really didn't provide any advantage to anyone, though we almost always delivered our commitment. In fact it just made us under-commit, which is actually not a bad thing. We almost always did more than the committed amount.

We gave up the whole commitment thing and went to a limited WIP type approach. We plan enough stories to keep us busy for a few days. We might plan a couple more to have "on deck", because our remote guy in India sometimes runs out of work in the middle of our night. If so, he can pick up an "on deck" story.

Our velocity was the same or better after this - we pretty much ignore our velocity but the business peeps use it to get an idea for planning. They have learned not to plan more than 3 sprints ahead, though. Priorities *always* change.
Tobias Mayer said…
People always seem to talk about "Sprint commitment" and "limited WIP" as if they are two separate things. They are not. You can have both. Making commitments to a goal is sometimes important not because making promises is important, but because the dialog the commitment generates can be really, really, useful for a team to figure out how to do do things like reduce over-work, do the simplest thing that will work, etc. Once a commitment is made, it is very satisfying to see the progress towards that goal, and acts as a motivator.

And we should ALWAYS minimize the amount of work in progress. Scrum is all about focus, which is one of its core values and has been from the very beginning. You cannot focus if you task-switch.

So make commitments, strive to meet them in a sensible way, reflect when you don't on why you didn't and adjust your behavior accordingly. And stay focused.

I agree with Richard that you may be focused on the wrong problem with the team described in the post.
Tobias Mayer said…
I should add that I am not talking about a story point- or velocity- based commitment, but just a gut-level commitment (at a business-value level) to either a sprint goal or a set of stories.
GeePawHill said…
Chris... I think this reeks of internalized pressure from outside forces.

For myself, I am increasingly trying to plan only at the release level, as a sanity check. At iteration level we just pull stories until it feels like everyone is working.

Your first point, that estimations are always wrong, is a key one. I ask myself how can I get away with not using them. I can't, yet, nut I can come close. -- GeePawHill
Yeswanth said…
This comment has been removed by a blog administrator.
sorna said…
This comment has been removed by a blog administrator.
TestWithUs said…
This comment has been removed by a blog administrator.

Popular posts from this blog

Reviewing "Context Driven Approach to Automation in Testing"

I recently had occasion to read the "Context Driven Approach to Automation in Testing". As a professional software tester with extensive experience in test automation at the user interface (both UI and API) for the last decade or more for organizations such as Thoughtworks, Wikipedia, Salesforce, and others, I found it a nostalgic mixture of FUD (Fear, Uncertainty, Doubt), propaganda, ignorance and obfuscation. 

It was weirdly nostalgic for me: take away the obfuscatory modern propaganda terminology and it could be an artifact directly out of the test automation landscape circa 1998 when vendors, in the absence of any competition, foisted broken tools like WinRunner and SilkTest on gullible customers, when Open Source was exotic, when the World Wide Web was novel. Times have changed since 1998, but the CDT approach to test automation has not changed with it. I'd like to point out the deficiencies in this document as a warning to people who might be tempted to take it se…

Watir is What You Use Instead When Local Conditions Make Automated Browser Testing Otherwise Difficult.

I spent last weekend in Toronto talking to Titus Fortner, Jeff "Cheezy" Morgan, Bret Pettichord, and a number of other experts involved with the Watir project. There are a few things you should know:

The primary audience and target user group for Watir is people who use programming languages other than Ruby, and also people who do little or no programming at all. Let's say that again:

The most important audience for Watir is not Ruby programmers 
Let's talk about "local conditions":

it may be that the language in which you work does not support Selenium
I have been involved with Watir since the very beginning, but I started using modern Watir with the Wikimedia Foundation to test Wikipedia software. The main language of Wikipedia is PHP, in which Selenium is not fully supported, and in which automated testing in general is difficult. Watir/Ruby was a great choice to do browser testing.  At the time we started the project, there were no selenium bindings for …

Open letter to the Association for Software Testing

To the Association for Software Testing:

Considering the discussion in the software testing community with regard to my blog post "Test is a Ghetto", I ask the Board of the AST  to release a statement regarding the relationship of the AST with Keith Klain and Per Scholas, particularly in regard to the lawsuit for fraud filed by Doran Jones (PDF download link) .

The AST has a Code of Ethics  and I also ask the AST Board to release a public statement on whether the AST would consider creating an Ethics Committee similar to, or as a part of the recently created Committee on Standards and Professional Practices.

The yearly election for the Board of the AST happens in just a few weeks, and I hope that the candidates for the Board and the voting members of the Association for Software Testing will consider these requests with the gravity they deserve.