I'm in total agreement with you and has often clashed with stakeholders (read management) who don't understand the dynamics of an agile environment. Legacy (read mindset) is the biggest challenge many teams will have to deal with. Reason? Majorities of stakeholders still come from the school of thought where milestones were created and embraced a false belief that they will be achieved. Again, there is the problem where stakeholders want to equate velocity to some kind of monetary measure, thus adding more problems to current complexities

Good points, Job. I’ve said before that I don’t think many organizations will get fully agile until they get managers like that to retire. :(

For the ability to allow future planning, not disappointing, I would rather the team planned for what they know the CAN do. Estimate (in our team) are usually a bit out and so trying to "stretch" = disappointed. Which in my view, the team themselves is constantly under pressure and don't get the chance to feel the success of completing their goals. I also like to ensure there is capacity for the unexpected, because I have learned to expect the unexpected ;)

Well put, Scott. Harvard professor Teresa Amabile has written about the frequency of small wins being a major factor in job satisfaction. Finishing what was planned into (most) sprints will give a team that feeling of success.

There's a common discussion of the difference between getting to 100% 70% of the time vs. getting to 70% 100% of the time. I'm pretty sure the former is what you're recommending to aim for (as I think I might have learned this 70% thing from you), but it's easy for "aim for 70%" to get into people's heads and start turning into the latter.

I have.. opinions about "KR70"s and stretch goals as a corporate culture, which I may someday express more thoroughly than this margin allows.

I agree that there is a lot of confusion concerning the definition of 70-80% of the time. My view was the former as you stated but almost everyone else in my organization believe it to be the latter. I would really like to know what Mike's view is on this one.

I thought I was more clean when I wrote this. But I re-read it tonight and I’m going to add a couple of sentences to make it really super clear. My view is that 70-80% of the time a team should finish 100% of what it planned or should at least achieve the sprint goal.

Finishing only 70% of what they plan every time would be horrible—for the organization and the morale of team members.

Hi Christopher,
What I want is 70-80% of the time the team either finishes 100% of what they brought into the sprint or at least meets the sprint goal. Achieving only 70% of what they plan every sprint would be horrible.

I suspect you and I agree on key results being considered successful at lower rates as well as about stretch goals.

Thanks for commenting.

This topic comes down to overall predictability, right? That is, if there is consistent performance each sprint, then there is enough predictability that allows us to reliably answer the question, “When will it be done?”

Now, consistency itself is not enough. An acceptable level of performance (work item delivery rate) should be that which is consistent. In the context of a “probabilistic forecast,” then we should target a level of risk the organization is comfortable with.

If 85% of our work items are delivered inside our sprint boundary, and that offers a reliable prediction for the business to make decisions around, then a scrum team can feel very good about that.

The team can then look to improve by delivering more items at that same 85% level using better teaming practices, etc. That will move the forecast to the left.

David Vacanti, call your office :)

Great post Mike! Being able to meet a aggressive sprint goal 3/4 times would be a radical improvement than the current situation of most teams and organizations...
I have seen conservativeness creeping in due to unsafe environments where the Product Owners, Engineering managers and the executive leadership try to drive "100% correct" plans down to the teams, asking them to list down everything they would achieve in a Sprint, month and quarter upfront! In such situations, teams feel better off to pull in what they would likely complete in a much lesser time, rather than what they would likely achieve. On top of that, they would be reluctant to address feedback, hesitant to report progress and also be demotivated due to lesser collective achievement. This would fail empiricism and thus put them on a path of conformity rather than agility.

Thanks, and I agree—it’s really hard for a team to go fast when they’re too conservative in what they plan for a sprint.

Hi Mike and all,

When you say that team should targer to finish 100% work with 70-80% time, its ok to get it but i wonder how can we tell the team when we are in the Sprint Planning? somethings like “ok now we only pick tasks that we think we can finish at day 8/10 of the sprint” ?

And my other questions is when the team usually finish everything at 70-80% so what do they do with the remaining duration? ( pick another tasks? or do something else? )

Hi Tân,

Good question. You want to tell the team to pick a set of work they feel “reasonably comfortable” completing. They should not feel it’ll be easy or that it will be impossible. It may take them a number of sprints to do this successfully.

But based on your second question, I’m worried I may not have explained myself very well. In the 8 out of 10 sprints (80%) in which the team finishes 100% of their work, they usually won’t have a lot of extra time to bring something in. Normally 1-2 people will be done early. If so they should try to help those who aren’t quite done. Maybe one can, one cannot.
And so the person grabs whatever work makes sense. That might be getting started on a some product backlog item, working on some code cleanup (paying off tech debt), or just something personal like catching up on reading or learning a new skill. Nothing about what I’ve suggested in targeting finishing everything most (but not all) of the time changes that. So it’s not like in the sprints where the team finishes everything that it was easy and they have a lot of time left.

I'd agree Mike. Software development involves people, so psychology inevitably plays a major part. Getting the balance right is crucial of course. A team that accepts that it's OK to routinely NOT deliver the sprint content they agreed to deliver is not good either. You don't want that becoming a habit. But accepting you can aspire without being hung out to dry if you fall short gives folks the confidence to say 'yes'.

I think not delivering routinely is one of the worst habits an agile team falls into. When they do, iterations become meaningless.

I like a lot of what you wrote here, except for two things.

First, the section about handling when a guarantee is needed. Your mindset cements the symptom to remain a part of the solution.

When the going gets tough, declare that I need a guarantee and I should be able to bypass everything else, every time, cause that's the way the teams is suggested to respond.

Not a very responsible way of thinking, especially to a wide audience struggling with the constant misuse of Sprint Goals and Sprints. Instead, I'd advise on bringing the person who needs the guarantee into the situation, earlier. Agile principle #4. Become partners of success! Try making a deal with each other...

"We will collaborate and align on the outcome needed most. We will be transparent with what we feel is the required scope, with respect to quality and tech-debt. In exchange, we will rely on you to help enable us to avoid implementing unnecessary scope while you also will never promise a delivery date prior to these partnership activities taking place. Agreed?"

The only other thing you wrote which I latched onto as problematic in that same section, is forgetting that learning is essential. It's built into the activities taking place during the Sprint. That means, treating the Sprint as a commit of output...that somehow transforming the Scrum Value verb into a noun, is acceptable, worthy of being overlooked, and/or tolerated as business as usual!

Any resistance to a suggestion like this, requires an inspection of motivations and/or incentives. Do we actually care about the same results? There should be no hesitation to plan an estimated amount of flexibility needed to enable adaptation, and to apply learnings. Discover the influences for a mindset supporting otherwise.

"...transforming the Scrum Value verb into a noun..."
What verb is in "Scrum Value"?

I don't know what the italics represent--they definitely aren't quotes from what I wrote. Thanks for sharing where you disagree--it gives me something to consider as I continue to encounter these situations.

Hi Mike
Totally agree for 80 % of predictability level to be a good achievement for a sprint.
For 100 % one it depends, normally it doesnot "smell" well, but if stretch items where delivered and we cannot have 120 % predictibility as they do not count for this metrics, then that 100% is a positive result.
hope this helps

I fully agree! Unfortunately, I have the opposite issue. The team insist that they can handle the 80 weight even though they end up every sprint just lifting 50. In almost two years, they are yet to successfully complete a sprint. I show them the stats and urge them to reconsider, but next sprint it is the same story. I do not know what else I can try :(

Wow—two years without finishing everything. That’s got to be really frustrating.

I will say, though, that one of the best teams I ever worked with had a similar problem. They had one guy on the team who had a very positive we-can-do-it attitude. He was the respected unofficial leader of the group and that personality rubbed off on all of them. Part of that was great but they only finished everything when they got lucky occasionally.

I handle this by having teams dramatically undercommit. If your team plans 80, gets 50, I’d have them plan 40 and tell them we want to feel what it’s like to add to a sprint rather than always drop.

Try for some sprints to plan only 50, so the team can deliver 100% (or very close) of what they planned. Then discuss with the team if and how increase their capacity.

Great advice, Enrico.

The sad reality I find is that despite the agile maturity of respective stakeholders, 9 out of 10, these stakeholders do need a guarantee of what will be delivered in a sprint. Continual coaching goes into correcting this mentality.

Most stakeholders I’ve spoken to understand that a guarantee will involve a team planning to do less. I’ve made that point, for example, by asking a VP of Sales how he set quotas for salespeople. That is, were they guarantees?

I read this differently.i.e. guarantee of what would be delivered in the sprints = what are the priorities for the sprint? As long as the "key" deliverables don't exceed the sprint capacity, shouldn't that be fine? Moreover, it also sounds like the stakeholders have left it to you to decide, and are not insisting on a certain volume of work..