Come Prepared
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 risk having an ineffective, stressful meeting: You are likely to perform backlog and planning work in a comparatively short, time-boxed meeting. This makes the sprint planning meeting challenging, and it can leave the development team feeling exhausted rather than motivated to start the new sprint.
Secondly, 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 that 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.
Be Present
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 two 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 development 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.
Secondly, 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.
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 that relate to the sprint goal can be done, the team has the right to push back and decline adding more work to the sprint.
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 and get the work done.
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.
The post Sprint Planning Tips for Product Owners appeared first on Roman Pichler.
Sprint Planning Tips for Product Owners posted first on premiumwarezstore.blogspot.com
No comments:
Post a Comment