As its name suggests, the sprint planning meeting sets up the sprint and establishes what can be done. While it’s an important meeting, I find that some product owners struggle with it. The following tips help you reflect on how you use the meeting and discover how you can get the most out of it.
Make sure you carry out the necessary prep work prior to the sprint planning meeting. Be clear on what you want the sprint to achieve, ensure that the product backlog is appropriately refined (or groomed), and have its high-priority items ready. This is necessary for the following two reasons:
First, if you start sprint planning without a properly prepared product backlog, you are likely to perform backlog and planning work in a comparatively short, time-boxed meeting. This makes the sprint planning work challenging, and it can leave the development team feeling exhausted and stressed rather than motivated to start the new sprint.
Second, once the planning is done and a sprint goal has been agreed, you cannot, or at least should not, change the sprint contents: Sprints are protected from changes in order to allow the team to work in a focused manner and do a good job.
Bear in mind that product backlog grooming should be a team effort and that you should involve the development team members in the backlog work. For advise on when to carry out product backlog grooming, please see my article “When should Product Backlog Grooming Take Place?”.
Focus on the Sprint Goal
While there are numerous planning techniques available to determine how much work can be done in a sprint—from using net hours to velocity-based planning, you should not have to worry about how the team plans. It’s up to the team to choose the right planning techniques and determine the right tasks, and it’s up to the Scrum Master to support the team members and suggest appropriate techniques when necessary. As the product owner, you should focus on establishing a shared, meaningful sprint goal that guides the work of the team and explains why the work is carried out. If you don’t have a Scrum Master, then that’s an issue that needs to be addressed: Taking on Scrum Master duties is likely to either overwhelm you and / or cause you to neglect some of your product management responsibilities, as I explain in “Every Great Product Owner Needs a Great Scrum Master“.
A sprint goal might address a specific risk and help you acquire the relevant knowledge, or it might be about completing or optimising a piece of functionality. An example of the former would be “Find out if users are willing to share personal data as part of the initial registration process” to address a user-interaction risk. An example for the latter might be “Finish the dashboard so it can be released to the test users”. If you work with release goals, which is something I usually encourage, then every sprint goal should be a step towards the next release goal.
While my experience suggests that many product owners don’t use sprint goals, I find them tremendously helpful. They provide purpose and alignment; they facilitate stakeholder communication; and they make it easier to analyse and action the data obtained from exposing a product increment to the users. But to fully leverage sprint goals, you must ensure that they are meaningful to the development team so that people support them.
If you believe, for example, that addressing a user interaction or pricing-related risk should be the goal of the sprint, but the dev team insists on first addressing a crucial technical risk, then it may not be a good idea to force your goal onto the team. Instead, search for an inclusive and shared goal that everyone agrees with. Alternatively, use two separate goals, as long as this is the exception and not the norm: Working with one shared sprint goal is the default in Scrum, as this fosters close teamwork and collaboration. Additionally, it tends to make it easier to collect and analyse the relevant user feedback.
I like to identify a candidate sprint goal as part of the grooming work. This avoids the risk of starting sprint planning without a firm idea why the sprint should be carried out. Once a shared goal has been agreed, the development team performs the planning work and validates if the goal is realistic. If that’s not the case, then you will have to adjust the goal and make it less ambitious until it fits into the sprint. You can download my sprint goal template, which helps you formulate clear and testable sprint goals.
As the product owner, you may have many duties competing for your time and attention; attending yet another sprint planning meeting might not be your highest priority. While that’s understandable, I recommend that you make an effort to be present during the entire meeting. Be in the same room as the development team if you can. Alternatively, attend via a videoconference.
There are three reasons for this: First, the sprint planning meeting is where the rubber hits the road. It determines what actually gets done, what is implemented in the coming days and weeks. By being present you can guide the development team and answer questions. This helps the team do a great job and reduces the need for you to answer questions during the sprint, which in turn, frees up your time to take care of other duties like competitor analysis and other strategic work. And having attended plenty of sprint planning meetings over the years, I find that new questions often arise when the development team members analyse the product backlog items and break them into tasks.
Second, as mentioned before, it may turn out that the initial sprint goal is not realistic and therefore has to be adjusted. If you are not present, then you won’t be able to influence and contribute to reshaping the goal. Additionally, you may want to understand why the goal cannot be reached so you can learn from it.
Last but not least, by being present you show the team that you care and that the sprint is important to you. This increases people’s motivation to gave a successful planning meeting and a successful sprint.
Respect the Team’s Right to Say No, but Hold People Accountable
Software development is an exciting but demanding profession. While I don’t want to overdramatise, I have met several people who have suffered from heart attacks and lasting food intolerances due to the high stress levels they experienced. Consequently, agile methods promote sustainable pace: The work load and intensity have to be sustainable over an extended period of time resulting a healthy work environment that fosters creativity and innovation. Scrum ensures sustainable pace by empowering the development team members to determine the right work load for a sprint. Consequently, if it turns out that not all of the high-priority items related to the sprint goal can get done, the team has the right to push back and decline taking on the appropriate items.
While you might feel that fully meeting the sprint goal is a must—you might face some challenging stakeholder expectations or you might have promised certain features, for example—you should refrain from trying to force more work onto the team. This will damage the team’s ownership and responsibility; the team will no longer feel fully accountable for reaching the sprint goal, as you essentially dictate it. In the worst case, people lose interest and motivation, and no longer care about the product.
At the same token, hold the development team accountable for meeting an agreed sprint goal at the end of the sprint in the sprint review meeting. If the team has the right to determine how much work they can take on, then people also have the obligation to meet the goal. But don’t mistake a commitment for a guarantee. Unforeseen things can happen in software development including people falling ill and a server going down. Additionally, newly formed teams often require some time to be able to realistically plan and reliably reach the sprint goals. But if your team has not learnt to make realistic commitments after three or four sprints, or if your team regularly fails to get all the product backlog items done that were pulled into the sprint, then use the next sprint retrospective to investigate and eliminate the causes.
Post a Comment or Ask a Question
Good blog on sprint planning. Thanks for sharing
I am in a pretty much the same situation as a PO.
What helps a lot is long-term planning, so that the topics for a sprint stay coherent. My goal is always to work on one or two components at the time, and to cover both bug fixes and new features. This reduces the context switching that is otherwise exhausting, both for team and for PO, and speeds up the whole development process.
This plan can be interrupted when blocker bugs occur, that have to be tackled immediately. Here comes another task for the PO: adequate priorisation of what is a blocker and what can wait, so that sprints can still remain coherent for most of the time. True blockers are solved immediately, the rest remains in backlog.
In the begining, the stakeholders may be against this, but they can be convinced in favor of it: it is much better for users to have a whole feature once in several months, than to get incomplete pieces of it every 2-3 weeks.
Thanks for sharing your approach George.
In my company I listen to many teams complaining they cannot set sprint goals, mainly because these teams are in charge of the maintenance of many different products, and the work of many sprints consists of small increments for some of the products they maintain. So for instance they could have 5 stories in a sprint backlog, each being an increment of a different product not related to each other. The sprint backlog looks more like a shopping list than something focused on a specific goal.
Have you ever experienced something like this? Is there a way to craft a sprint goal in this kind of situations?
Thanks for sharing your question Andrea. In situations like yours, I recommend experimenting with a Kanban-based process. Please take a look at my articles “Is Scrum Right for Your Product?” and “Succeeding with Innovation and Maintenance“.