I got the idea of writing this blog while hosting a webinar on the same topics when multiple people told us to document our discussion. Originally, I posted this blog on Agilemania, where you can also find information about our upcoming webinars.
These dos and don'ts are based on my experiences, so I would love to hear yours as well. Feel free to connect with me on LinkedIn for further discussion.
Top 5 Things You Should Do During Sprint Planning
1st – Craft Sprint Goal
As per the Scrum Guide, the Sprint Goal is an objective that will be met within the sprint by implementing the Product Backlog, and it guides the Development Team on why it is building the Increment.
During the Sprint Planning, the Product Owner presents business objectives for the Sprint and an ordered Product Backlog. The Scrum Team discusses what can be done based on the Definition of Done and crafts the Sprint Goal and forecasts their work. Scrum Teams ensure they have a meaningful Sprint goal, not a Generic goal. For example, “policy renewal for individual policyholders” for an insurance product, rather than saying, the goal is “complete all Product Backlog Items selected during the Sprint.”
Challenges in crafting the Sprint Goal:-
- The team has random Product Backlog Items, which makes it difficult for them to craft a sprint goal. It can be avoided by having an ordered product backlog, but if it is still needed, the team can ask the product owner about the most crucial Product Backlog Item and set a goal around that.
- The team picks up work for more than one product because they support multiple products. The team can avoid this by widening the definition of a product or shortening the Sprint duration.
- Team is working on multiple components, and Items are for components, not for a feature. Avoid such issues by having user-centric features as a Backlog item.
- The team is working on support items, including defects, incidents, and service requests. A meaningful Sprint Goal optimizes and improves product quality to reduce such defects and incidents.
2nd – Pick at least one retrospective commitment for the sprint
The purpose of the Retrospective is to enhance the way of working by adopting new processes, practices, and tools, or by improving team collaboration and relationships among team members. Since the team has come up with a few Retrospective commitments, the team must plan 1-2 items for the Sprint, or else it will never get adopted, and teams may struggle to understand the retrospective’s usefulness. For example, the team has agreed to develop mock-ups for Backlog items to gain more clarity upfront to reduce ambiguity, so they must consider and plan the same in the Sprint.
3rd – Refer Definition of Done
The Definition of Done is a common understanding within the Scrum Team on what DONE means, and it evolves as the team learns more about the product and technical skills. It reflects the maturity of the team and improves the quality of a product. Referring to the Definition of Done helps the team to understand how much work they can plan for the Sprint. An exhaustive list of items in the Definition of Done results in fewer product backlog items, as teams must complete a significantly larger scope to fulfill each Backlog item. For example, if the team has added automated regression testing to improve quality, it may need a little more time to write an automated test script for Backlog items.
4th – Review Team capacity
The velocity is good to forecast, but only when the team remains the same and works in a consistent sprint cycle. If any of these changes or a few holidays are coming up, it is better to check available team capacity during planning, besides team velocity.
5th – Come up with a plan for the initial few days
Since sprint planning is a timebox and the team must respect the timebox, sometimes teams struggle to formulate the Sprint Plan. For instance, there is ambiguity in requirements or team dynamics, making it unclear how to improve without planning more. It may turn out to be counterproductive. It doesn’t mean teams should not prepare a plan, but having a lightweight plan for the initial few days is good enough to start. Teams can reconvene during development to plan, as they gain a deeper understanding of requirements and effective work methods.
Top 5 Things You Should Avoid Doing During Sprint Planning
1st – Don’t assign stories to developers
The Development Team pulls work from the Product Backlog to the Sprint Backlog, and I think everyone understands that. The Product Owner or the Scrum Master should not assign work to the Development Team. The Development Team Members should not just divide into "your story" and "my story" categories. The Development Team should explore the possibility of completing stories incrementally within the Sprint by working together. It is more like 2-3 team members work on one story together, completing it within 2-4 days. It helps minimize spillover by allowing them to receive feedback early and adjust changes as needed. It also helps the team care about each other and learn each different skills to support when needed.
2nd – Don’t create skills-based tasks
Having sub-tasks like design, coding, writing test cases, functional testing, and code reviews, etc., promotes a mini-waterfall kind of process during development. Not having sub-tasks may sound good, but it has to be done carefully to avoid transparency issues. Having component-based tasks, such as mobile interface, web interface, backend service, and integration, is better as it promotes collective ownership. Skill-based tasks may impact transparency and generate more technical debts, too. You can read more about it here.
3rd – Don’t force the development team to match the velocity
Velocity is not a way to measure productivity. Discover how to maximize work value by empowering teams to focus on high-value Product Backlog Items. Velocity is good for forecasting when there is no change in the Sprint cycle and team composition. It is like, based on highway speed, one cannot help but wonder how much one can travel in an hour in city traffic. Similarly, changing drivers will impact speed, so it is not possible to forecast based on the previous driver's velocity if there is a new driver.
4th – Don’t plan only defects for the sprint
Focus on reducing defects by identifying and addressing the influencing factors that cause them. Having a few stories helps in learning the expectations of the stakeholders. See how the team plans to reduce the technical debt because more technical debts mean a higher total cost of ownership. Look for opportunities to adopt excellent technical practices, such as Behavior-Driven Development, Agile Analysis, and other Extreme Programming practices.
5th – Don’t have a generic sprint goal
A generic goal doesn’t define a clear purpose of the Sprint. Have a specific sprint goal and order Product Backlog Items around that to help the team stay focused throughout development. Goals like high-quality work, meeting all acceptance criteria, or delivering all the backlog items are not good goals, and these are part of the Definition of Done. Consider the users and how they can benefit from the Sprint's outcome.
Role of The Product Owner during Sprint Planning
- Come prepared by having a clear objective for the Sprint and share it with the team
- Keep the Product Backlog ordered and aligned with the objective so the Scrum Team can craft the Sprint Goal easily.
- Respect self-organization and avoid demanding that the team is uncomfortable with; instead, collaborate to explore what the team can achieve within its constraints.
- Guide the Team in forecasting stories by understanding team confidence and looking at available capacity.
- Support the Development Team in preparing a plan to meet the sprint goal. Working as a coach during the planning process helps the team think like the customer, adopt a systematic view, and avoid local optimization.
Role of The Scrum Master during Sprint Planning
- Collaborate as peer team members to craft the sprint goal. It is not true that the Scrum Master only acts as a facilitator. The Scrum Master is part of the Scrum Team, and the Scrum Team defines the Sprint Goal.
- Coach them during forecasting stories if needed by asking powerful questions, such as how they will feel if they fail to meet the forecast, which helps in having a potentially releasable increment. How are they planning to work as a team?
- Ensure the team understands what to inspect and adapt during the sprint planning. Is the team inspecting the latest Increment, the definition of done, retrospective commitments, and team combinations, etc.?
- Enable transparency by helping them understand how a good sprint backlog can foster a sense of care for one another and serve as an information radiator.
- Facilitate Sprint Planning if needed to ensure everyone respects the timebox, comes up with the sprint goal, and plans for the initial few days.
Role of The Development Team during Sprint Planning
- Ensure that stories have acceptance criteria; if not, collaborate with the product owner to create some. This helps guide the team in understanding what is needed to complete a story.
- Avoid rushing into forecasting by picking up stories based on the previous team’s velocity. Spend time to understand, even if these were refined/groomed, because some new information might have emerged lately. If a story seems big, then split it like a slice of cake to ensure it still delivers value to the customers/users.
- Craft the Sprint Goal together with the Product Owner and the Scrum Master, as it will help the team understand the Sprint’s purpose. The purpose is one of the key motivators for knowledge workers, as Daniel Pink mentioned in his book called “Drive.”
- Discuss design and how to accomplish stories through planning, rather than just picking up work. The Scrum framework doesn’t mention when to discuss and decide on design and architecture. Still, my experience suggests that product backlog refinement and sprint planning have been good places to discuss these.
- Refer to the Definition of Done while coming up with a plan, as it may influence the amount of work a team can forecast during the sprint planning.
If you want to learn further about it through training, join our upcoming Scrum Master Training or request for a private workshop for your team. Feel free to connect with me on LinkedIn and subscribe to my blog on Medium.