Scrum team committments

Question

If my Scrum team is always completing 100% of their committed items, is that a good thing? Given the amount of variability in software development, this would seem to indicate something is fishy to me, but the prevailing philosophy seems to be that something is if they aren't always completing 100% of committed scope.

If you think that not completing 100% of committed scope every sprint is ok, what % of the time would you expect them to be wrong, and how far off would you expect them to be before you thought there was a problem that needed to be directly addressed?

Answer 1

TL;DR

The goal of Scrum is really to build trust through reliable and sustainable delivery of potentially-shippable increments of value. If your process is already doing that, don't break it. If it's not doing that, then some continuous improvement and inspect-and-adapt is certainly in order.

Utilization: Less Important Than Trust and Reliable/Sustainable Cadence

In Scrum, the goal isn't 100% utilization but sustainable pacing and reasonable accuracy, part of which is ensuring the team doesn't mis-estimate its work or routinely commit to work that it can't complete within a single iteration. So, regularly completing 100% of committed scope is great.

What you're really asking is something else. The hidden question seems to be: "If my team is always delivering 100% of agreed-upon scope, does that mean they aren't busy enough?" In other words, you're asking whether they have excess slack in the process, and if they should be committing to more work each iteration.

Maybe.

This is good fodder for a retrospective. If the team is completing all committed work halfway through the iteration, then they probably are mis-estimating or not accepting enough story points into the Sprint. However, if they are routinely completing all work that they commit to, have enough slack to ensure that they can handle variances and roadblocks, and aren't "sprinting" so hard that they burn out, then pouring on more work isn't necessarily constructive.

How to Inspect-and-Adapt Your Current Scrum Implementation

Instead of asking whether your team is under-utilized, a better set of questions might include:

1. Is the team's delivery cadence adequate for the business' needs?
2. What's driving the business' desire for a faster delivery cadence? (Hint: perhaps there's a trust issue or hidden process issue that needs to be addressed.)
3. If the business wants a faster delivery cadence, are they willing to accept the risk that some Sprints may deliver less than 100% of accepted work?
4. Is the team able to sustain an increased cadence without sacrificing quality, scope, or the Definition of Done?

Remember to start with an analysis of the major premise. In this case, that means asking why meeting 100% of commitments isn't seen as a good thing. There may be legitimate reasons why this isn't good enough, but make sure you (and the team) understand what those reasons are so that the team as a whole can address the underlying organizational and process issues.

Conclusion

If the team is meeting the business' current needs, and the team is happy and productive, then I wouldn't recommend messing with success. On the other hand, if the process isn't meeting organizational objectives, or if there are trust issues between the team and the larger organization, then that's definitely a discussion that needs to be had.

Answer 2

It depends; after completing the original sprint backlog, do they always pull more, and get unexpected work done? This creates a characteristic sawtooth pattern at the end of the burndown chart that is the signature of teams that go the extra mile. After completing all work in sprints, do they pull more work in the next sprint, to take advantage of their capacity? Teams that regularly do this are on their way to ever-higher performance. If however, their velocity is flat, and their burndown ends on or before the end of the sprint, that would explain the fishy smell. Teams doing that usually feel pressure from those in authority to always complete their sprint work. They are responding by being very careful not to challenge themselves, so are not innovating, learning, or improving as much as they could. I'm not sure how much variability is "expected", but certainly some. Similarly, "too much" may not be easily specifiable in a general way, so be sure to pay attention to feedback from the PO, customers & stakeholders, who will be affected.

Answer 3

The development team has two main responsibilities. The first is to deliver business value at a level of engineering quality that is appropriate to the organisation. The second is to look for areas it can improve.

Both of these responsibilities require the team spends time thinking about what they do. They may need to research new technologies, talk about their design/architecture and continually inspect their approach. If a team is packing work in so that they are frequently working flat-out until the end of the sprint then they will have little time for introspection and improvement. In other words, some slack time is a good thing.

Of course there is a balance to be achieved. A professional Scrum team will strive to find the right balance between delivery and self-improvement. Continually adjusting their approach based on circumstances.

Answer 4

100% completion of committed user stories is ok but as said by CodeGnome a good point for the next retrospective. Maybe your team is too defensive and could achieve even more during one sprint.

Why are 100% OK? What you want is a team that understands the stories (from the product owners point of view) and estimates their complexity in story points. After some sprints, the burn down should become stable and the "usual" points per sprint should be known. This is a great thing, when the product owner prioritises the Backlog.

It's also OK, if not all committed points could be achieved (always). The team should find the root source for the issue in the retrospective to get back to ~100%. I'm not able to say how large the deviation is allowed to be - but go for "small".

It's the teams intrinsic intension to not be lazy. If the team is not familiar with the scrum understanding of the team, the Scrum Master should transport the idea and work on a positive atmosphere.