When there’s so much pressure to get work done, preplanning a Sprint with the whole team may appear to be a waste of time. Why drag the entire group through a preplanning exercise? Wouldn’t it be more efficient to have a single person take the responsibility of preplanning a sprint to share with the team? This would allow the team more time to do “actual” work, right?
Definitions:
Planning Ceremony – One of the main Scrum ceremonies is planning. Planning occurs when the team comes together to schedule their work for the upcoming Sprint.
The purpose is to determine what can be delivered in the upcoming Sprint. The team commits as a group to complete a certain amount of work. Preplanning a sprint as a team offers several advantages, such as the team making micro-adjustments in the work order to handle dependencies and nuances of sequencing the work.
Before beginning the planning session, the Product Owner brings the prioritized list (backlog) of work to the meeting.
The main steps include:
Reviewing the product backlog
Estimating the workload
Selecting the work
Setting sprint goals
Decomposition of larger items into more manageable (smaller) items
And, finally, team commitment to the Sprint goals.
The outcomes include a clear Sprint goal, a Sprint backlog containing the items the team can commit to completing, and a shared understanding of the scope, objectives, and approach of the upcoming Sprint.
PBI – or Product Backlog Items. That is, the list of tasks or stories in the backlog.
Suck -----------|-----------|----------|--------- Awesome
Suck – No planning at all. Tickets are injected whenever without prioritization or estimation.
Good – Planning occurs but doesn’t include the details needed. This can antidotally be measured by missing the goal of the Sprint, not finishing all of the work, or the need for continuous extraordinary effort.
Awesome – Before beginning the Sprint, the Product Owner surveys the Stakeholders to define and prioritize the work. The team then reexamines, estimates, and micro-adjusts the backlog as it is assimilated into the next Sprint.
How to Optimize Preplanning a Sprint as a Team
Illusion of Certainty
So… if some planning is good, more planning is better, right?
Most of the time, my job includes trying to convince Management of the value of a Product Owner. But occasionally, I have the opposite issue. I’m working with an overenthusiastic Product Owner—somebody who not only gathers the priorities but also breaks down the stories into smaller parts, estimates each piece, designs the approach, determines what stories will be completed, and prepopulates the Sprint, so the team doesn’t have to concern itself with all of that work.
Even if the Product Owner is an expert on the subject matter and the technology, they would have to know very detailed background information on the existing system, the issues, and several other factors to preplan effectively.
Even then, when the stories are presented to the team, the team may collectively brainstorm on the fly and devise different, more efficient ways to perform the work. The team may also know of a technical debt that needs to be dealt with before they can move forward. Or maybe one of the team members will be absent for part of the Sprint.
The illusion of certainty is common in every company. Spreadsheets and project management tools are great for getting organized, but the tools rarely embody the nuances that exist when planning complex work.
Before the Sprint Planning
The Product Owner should meet with the Stakeholders to review priorities on an ongoing basis. It is important before the Sprint to align priorities and flush out the business details.
The Product Owner should, with the direction of the Stakeholder, take the first pass and organize the backlog (grooming). But when you bring the prioritized backlog to the team, you must be okay with some modifications. At times, the whole list may change, so it’s better not to get too attached to the original priorities.
That said, there also shouldn’t be any surprises that would cause a complete rework. If you must completely replan the whole backlog, that indicates something was missed.
Here’s a list of activities a Product Owner should prepare for Preplanning a Sprint:
1. Refine Product Backlog:
Prioritize: Ensure the Product Backlog Items (PBIs, often referred to as user stories or features) are prioritized based on their value to the customer, Stakeholder feedback, and other business objectives.
Detailing: Elaborate on each PBI, ensuring there’s enough information for the Development Team to understand the requirements and provide estimates. This includes any designs, acceptance criteria, or other necessary details. * The task of product refinement should be continuous, but a focused effort may be required leading up to the Sprint.
2. Estimation Preparation:
If the team uses techniques like Planning Poker for estimating effort, ensure any necessary materials or tools are available.
Review any PBIs that have already been estimated to check if there have been significant changes that may require re-estimation.
3. Stakeholder Feedback:
Meet with Stakeholders to gather feedback on the product or any new requirements.
Ensure the updated Product Backlog reflects any new information or change in business priorities.
4. Clarify Dependencies:
Identify any dependencies between backlog items, be it technical, resource-related, or based on external teams/vendors.
It’s essential to understand these to ensure the team doesn’t commit to items that cannot be completed due to unresolved dependencies. * The team can help with dependency clarification, but if there are known dependencies, it helps to have them ready to discuss with the team.
5. Consider Technical Debt:
If any technical debt needs to be addressed, ensure it’s represented in the Product Backlog and prioritized accordingly.
6. Collaborate with Scrum Master:
Engage with the Scrum Master to discuss potential challenges, share insights about the upcoming Sprint, and coordinate logistical preparations.
7. Review Roadmap and Strategy:
Ensure the upcoming Sprint’s objectives align with the larger product roadmap and strategic goals.
8. Prepare the Sprint Goal:
Although the Sprint Goal is often finalized during the Sprint Planning meeting, come with a draft or proposal based on the priority items in the backlog.
During the Sprint Planning
During the Sprint Planning ceremony, the Product Owner should be available to clarify any questions. The Manifest for Agile Software Development states, “Individual and interactions over processes and tools.” The Product Owner should be acting as a proxy for the Stakeholders.
Here’s a list of Activities a Product Owner can assist with during the Planning Ceremony:
1. Present the Sprint Goal:
Start by providing a draft or proposal of the sprint goal that describes the overarching objective or outcome the Sprint should achieve.
2. Clarify the Prioritized Product Backlog Items (PBIs):
Present the top-priority items from the Product Backlog to the Development Team.
Ensure the team understands the value and importance of each item.
3. Answer Questions:
As the main bridge between the Stakeholders and the Development Team, the Product Owner should be prepared to answer questions about any of the PBIs, including the context, desired outcomes, or any other clarifying details.
4. Refine the Acceptance Criteria:
If there’s any ambiguity or if the Development Team seeks further clarification on the acceptance criteria of a PBI, the Product Owner should work with the team to clarify or refine them during the session.
5. Negotiate and Adjust:
Based on the team’s capacity and the effort estimation for each PBI, some negotiation may be needed. The Product Owner may have to adjust priorities or break down PBIs further based on the team’s feedback.
Negotiation in mature teams should be non-confrontational. Trust should be present so everyone knows they are working toward a common goal.
6. Highlight Dependencies:
The Product Owner should inform the Development Team of any known dependencies or constraints associated with the PBIs. This can help the team sequence their work better.
7. Stakeholder Insights:
Share any recent feedback, insights, or concerns from Stakeholders that could impact the Sprint’s direction or the treatment of specific backlog items. This is more than what needs to be done and includes why the Stakeholders want the additional capabilities.
8. Collaborate on the Final Sprint Goal:
Based on the PBIs selected for the Sprint and any emerging themes, work with the team to finalize the Sprint Goal to guide their focus and efforts.
9. Ensure Commitment:
While the Development Team commits to the Sprint Backlog, the Product Owner should ensure the team is comfortable and aligned with the commitment and understands the value and relevance of the work they’re taking on.
10. Documentation:
Any new insights, changes, or decisions made during the Sprint Planning should be documented or updated in the Product Backlog, Sprint Backlog, and any other relevant documentation.
11. Reaffirm Availability:
Confirm resources are available during the Sprint and key dates.
When It’s Time to Start Over
Here are some good reasons you might have to replan the backlog completely:
A critical bug has recently been discovered.
The main stories of the Sprint have a block that wasn’t found until the Sprint planning had begun.
During planning, the team discovers that changing the Sprint or regrouping the work offers a major time or cost saving.
A dramatic shift in the business, such as a sale or merger. Typically, such large events take time to trickle through the business, but if you are working on a feature only your main competitor has, and you have just merged with that competitor, it may make sense to hold off on such a feature.
A sudden shift in the law. For example, the government may have recently announced a new ruling on an existing law. The ruling may modify an existing law that has already gone into effect. The company may find itself suddenly out of compliance.
You want to allow for flexibility in planning because the team often knows best. The team may lack knowledge of the larger forces at work within an organization, but it should know the best way to modify the systems toward a specific goal.
If You Must Prepopulate a Sprint
A purist would NEVER create a new Sprint before the current Sprint is completed. Given the current state of popular Agile tools, it is okay to cheat a little and create an extra Sprint as a placeholder to keep work organized if the team is fine with changing 100% of what is in the placeholder Sprint.
The advantage of using a Sprint vs. a prioritized backlog is that it is a clear indicator of what stories are desired in the next Sprint. Some tools allow you to tag user stories. The use of tags could create the same signaling without the hang-ups.
DO NOT WEAPONIZE this convenience!
The team still has the final say and will still need to discuss and point out the stories.
Here are some guidelines if you discover you must prepopulate a sprint:
Never prepopulate more than one Sprint out. That breaks the whole spirit of Agile. If you need to perform long-term planning, use a roadmap tool.
Don’t point out stories without the team.
Don’t fill the entire extra Sprint. Leave room for the team to populate some of the stories. If you end up always creating the Sprint ahead of time, the team will lose its ability to effectively populate a Sprint.
Don’t always create extra Sprints. If you feel the need during each Sprint, something else needs to be addressed.
A Better Approach to Preplanning a Sprint
Try putting the stories at the top of the backlog instead, even if your Agile planning tool doesn’t have robust capabilities. It is a nuance, but having the team pull the items into the Sprint vs. seeing the items already populated in the Sprint completely changes the team’s engagement level. Pulling tickets into a sprint should foster more meaningful conversations.
Always ask the team if there are any stories they feel take priority and why. Just the act of asking will go a long way, but not every participant may volunteer key information. By asking, you are getting agreement from the team.
Present to the team the value the Stakeholders are trying to describe. Review the “Why.” For example, the team may be unaware that a story was created to mitigate the risk associated with a new legal requirement.
Preplanning a Sprint Conclusion
Resist the temptation of completely preplanning a Sprint, but also find the time to prepare for the Sprint. Each team will require a different amount of planning to be successful. Some teams will need very detailed planning; others may need very little planning. Discussing the level of planning during the Retrospective is a good way to finetune what the team needs to be successful. It also allows the team to work out some of the mechanics of the planning process.
Over time, as the team practices planning, they become very effective at flushing out dependencies and prioritization. Collectively, the team will start finding opportunities no one individual could find.
Preplanning a Sprint too much restricts the team’s ability to perform at their best, so it’s all about finding the right balance of preparation.
Comments