How successful is your sprint planning?

Sprint planning is one of the standard events within the Scrum framework.

This ceremony or an adapted version has also been incorporated within other agile delivery frameworks which time-box the work of teams. The purpose of the ceremony is to align the team on what they will be working on during the upcoming sprint to ensure that their efforts are focused on delivering the highest priority work items in a quality manner while maintaining a sustainable pace of work.

Successful sprint planning lays the foundation for a successful sprint but this just completing the ceremony doesn’t mean it is delivering value.

Here are four common challenges which impact this critical ceremony.

Where is everybody?

Sprint planning is that singular opportunity to get everyone’s buy-in on what will be accomplished in the upcoming sprint. Partial participation means that decisions are being made on behalf of team members who are not in the room. That is likely to reduce their sense of ownership for the sprint backlog and increases the risk that work may be accepted which cannot be successfully delivered without heroics. While it might be convenient to conduct this ceremony first thing in the morning, the team should develop a sense of when they are likely to be fully present in mind and body and schedule it accordingly. Similarly, it is not advisable to start sprints on Mondays as that tends to be a more common day off than the middle days of the work week.

A lack of preparation

If the backlog doesn’t reflect the Product Owner’s priority, sprint planning is not the time to bring it up to date. Similarly, while highly mature teams are able to complete task identification, modeling, sizing or other preparatory activities during sprint planning, most others find that spending some effort in the previous sprint doing some look ahead planning will reduce the likelihood of running out of time in the ceremony or slicing off a sprint backlog with only a limited understanding of what needs to get done.

Appetite exceeds capability

Its normal for new teams to accept more work in a sprint backlog than they are realistically capable of delivering. However this gap between expected and actual velocity should reduce progressively sprint over sprint. When a lack of predictability regarding team capacity is not a blocker, teams which consistently take on more work than they are able to deliver are either demonstrating a lack of self-discipline or they lack the courage to educate autocratic external stakeholders on the dangers of accepting unrealistic commitments.

It’s my way or the highway

Whether it’s the Product Owner or a (supposedly) observing senior stakeholder, there’s no excuse for the development team being told how much work they will accept in a sprint.

Does your team experience any of these impediments? Is your team sufficiently self-aware and transparent such that these challenges are identified during retrospectives? If not, why not?