We had an online meet-up on this topic yesterday, and I felt we were a little off track as there was a large group of participants, so the discussion went in multiple directions. I think this happens with a large group of people and different levels of experience. To ensure that the objective gets fulfilled, I summarize here five dos and don’ts to refer back to. I expect our next meet-up on “The usefulness of Extreme Programming within the Scrum” scheduled for coming Saturday will be more useful. Feel free to subscribe here.

Top 5 things you should do during sprint planning 

1st – Craft Sprint Goal 

As per 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 forecast 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, so struggle to craft a sprint goal. It can be avoided by having 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 as they are supporting multiple products. The team can avoid by widening the definition of a product or shortening sprint duration. 
• Team working on multiple components and Items are for components, not for a feature. Avoid such issues through having user-centric features as a backlog item. 
• Team working on support items like 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 whole purpose of the retrospective is to improve the way of working either by adopting new processes, practices, and tools besides improving team collaboration and relationships among team members. Since the team has come up with a few retrospective commitments so the team must plan 1-2 items for the sprint 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 improving the quality of a product. Referring 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 means fewer product backlog items as teams has to do a lot more to complete each backlog item. For example, if the team has added automated regression testing to improve quality, it may need 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 working in the 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 example, there is ambiguity in requirements or teams, not sure how to do it better instead of 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 meet again to plan during the development as they learn more about requirements and ways to accomplish work. 

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 also not just divide like your story vs. my story. The Development Team should look for the possibility to see how they can complete stories incrementally within the Sprint by working together. It is more like 2-3 team members pull one story to complete within 2-4 days collectively. This helps in minimizing spillover as they can get feedback early to adjust changes if 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., promote 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 like mobile interface, web interface, backend service, integration, etc. 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. See how to maximize work value by enabling teams to work on high valued 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 speed on the highway cannot help measuring how much one can travel within an hour in city traffic. Similarly, changing drivers will impact speed, so not possible to forecast based on previous driver velocity if there is a new driver.  

4th – Don’t plan only defects for the sprint 

Focus on how to reduce defects by influencing factors that cause so many defects. 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 higher total cost of ownership. Look for possibilities 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 ordered product backlog items around that helps the team to stay focus throughout development. Goals like high-quality work, meet all acceptance criteria or deliver all the backlog items are not a good goal and these are part of the Definition of Done. Think about users and see how users can benefit from the outcome of the sprint. 

Role of The Product Owner during Sprint Planning 

• Come prepared by having a clear objective for the Sprint and share 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 do not demand that team is not comfortable with instead collaborate to see what can team do within constraints
• Guide Team in forecasting stories by understanding team confidence and looking at available capacity 
• Support Development Team in preparing a plan to meet the sprint goal. Working as a coach during the planning helps the team think like the customer, have a systematic view, and reduce local optimization.  

Role of The Scrum Master during Sprint Planning 

• Work as peer team members while crafting 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 like 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 understood 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 how a good sprint backlog can help care about each other and act 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

• Make sure stories have acceptance criteria, and if it is not there, work with the product owner to create a few, it helps guide the team to understand what all needed to complete a story.
• Do not rush in 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 deliver value to the customers/users. 
• Craft 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.”
• Talk about design and how to accomplish stories because you plan and not just pick up work. Scrum framework doesn’t mention when to discuss and decide design and architecture, but my experience says product backlog refinement and sprint planning has been a good place to discuss these. 
• Refer 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 me on LinkedIn and subscribe to my blog on Medium. 

Author's Bio

Naveen Kumar Singh

Naveen is a Lean-Agile Coach, Professional Scrum Trainer (PST) and Internationally acclaimed Speaker in many Conferences and Agile events. He has over 22 years of experience in multiple domains and he is a Certified LeSS Practitioner (Large-Scale Scrum) and one of the early adopters of DevOps practices and teaches DevOps culture around the Globe.