Five problems you meet on the way to Sprint Planning
In my coaching work, I often encounter some real head scratching scenarios. This is a #truestory, with only the names changed to protect the well-meaning, but not well-executing. It was Tuesday after a long weekend. Your Scrum Master has already “started” the sprint, in Jira...but you haven’t done Sprint Planning. When the Product Owner asks, the Scrum Master says “let’s do it now. So - the Scrum Master starts looking at the backlog and assigning tickets. 15 min in a developer drops for an appointment - because there was no meeting set up. The Product Owner sighs, the team rolls their eyes, and…another not-so-well designed sprint of work commences.
Clearly the wrong way to start a sprint. And while most of us do not regularly experience this level of dysfunction, we do often sit through bad planning sessions. As a Scrum Master and Product Owner I’ve made lots of mistakes in planning. And as a coach I’ve seen plenty of wonderful ways to waste a team’s time. With that in mind I thought I’d share 5 common problems that snag sprint planning - and would love to hear yours!
Your Product Owner doesn't come with value in mind
Understanding, communicating, and aligning the organization on what’s most valuable is the key function of a Product Owner. They must understand the value that the team can deliver in every dimension, and there are a near-infinite number of them. A few of the more important ones:
Customer value: What do our customers want, and what will they pay for?
Enterprise value: What does the organization need and want - how does my product fit into the strategy of the company?
Value over time: What is valuable now, and what will be valuable later?
Predictability: Can we deliver the features that will achieve the value?
Coming into Sprint Planning, the PO must synthesize these dimensions into a coherent set of value propositions to collaborate on with their team. While those can take the form of a proposed sprint goal, the PO is NOT responsible for creating the Sprint Goal.
During Sprint Planning, the PO needs to continuously point the team in the direction of value, surfacing their thoughts and research, and challenging the team to think through tradeoffs.
Once Sprint Planning is completed the PO needs to ensure that the organization is truly aligned around the Sprint Goal as the expression of value the team is working towards.
Your Scrum Master as secretary not coach
Lord of Jira is a cool sounding title but it’s not the responsibility of a Scrum Master. Your SM is the team’s coach, and Sprint Planning is an ideal setting for acting in that capacity. Is the team ignoring a critical point of view, or steamrolling over objections to “get done” with planning? Has the PO been effectively collaborating with the team to maximize the value of this sprint’s increment? How could the team, or individuals on the team, contribute more effectively? And is this session producing a viable goal, and plan to reach that goal? Your SM may be fingers-on-keyboard with Jira, but they should only take that role if it serves to increase team’s agility, and affords an opportunity for the SM to increase team effectiveness.
Letting the PO to define the Sprint Goal
The PO does not define the Sprint Goal.
The PO does not define the Sprint Goal.
The PO does not define the Sprint Goal.
One more time - the PO does not define the Sprint Goal.
Handing the Sprint Goal to a team is one of the most disempowering moves a PO can make, defining for the team what is to be achieved. Rather than collaborate to find the best goal, the team plays the role of curtailing the goal to fit the work that can be done. This pernicious pattern sets up the PO as Engineering Lead, the SM as Project Manager, and the Developers as hands-on-keyboards rather than brains-on-problems.
Stuffing the sprint with too much work
When the team has collaborated on creating a great Sprint Goal and the SM has coached them to high effectiveness it’s much easier to avoid the Planning Fallacy (the tendency to underestimate risks and overestimate our ability to achieve). Adding a few bug fixes, or some work for another team seems completely achievable. Expanding the work to include some “future proofing” is a wise investment. Even cautious teams will be tempted to add a stretch goal, secondary priorities, and “if we have time” activities. What teams often forget at this point is that the most critical resource they have is focus. They need to jealously guard their focus. And if, by chance, there’s extra capacity towards the end of the sprint - you can always pull in more work to achieve a stretch goal.
Not creating a plan for the Sprint
The Sprint Backlog consists of three items and teams need all three to be successful:
The Sprint Goal (The Why)
The Product Backlog Items (The What)
The Plan for delivering (The How)
Nobody tells the Developers how to do the work - that is, how to turn the selected Product Backlog Items into the Sprint Goal. This is often mistaken for nobody challenging the Developers to come up with a viable plan for the sprint. A good team will challenge the PO to better uncover, communicate, and align the organization on value. A good team will challenge the SM to uncover better ways of coaching, to improve the organization’s implementations of Scrum, and to remove barriers between stakeholders and the team. And a good team will challenge the Developers to come up with a resilient, appropriately detailed, and well considered plan for the sprint. Everyone contributes, especially to those responsibilities held by others - that collaboration is what makes a team great.
Plans are useless, but planning is indispensable
Yes Virginia, there is planning in Agile. A lot of planning. And it can feel like a waste of time if it’s not fit-for-purpose. Uncovering risks, aligning on the value the team will deliver, and operationalizing your sprint plan are crucial to having a successful sprint. The map doesn't help you succeed - our shared determination to address the unknowns, as a team, is the truly valuable, and indispensable, outcome of a well executed sprint planning session.