Rudiments of Sprint Planning

Sprint Planning is one of the most important ceremonies or activities within the Scrum methodology. In my blog today, I will take you through various aspects of sprint planning. 

Let’s discuss the following: 

• What is Sprint planning? 
• How to go about Sprint planning?
• What happens in Sprint planning?
• What are the artifacts from Sprint planning?
• How to set Sprint goals?

1. What is Sprint Planning 
Sprint planning establishes the Sprint goals where the team collaborates with the Product Owners (POs). Here, we discuss what can be accomplished and how it can be accomplished by creating the tasks, agreeing on the ‘Definition of Done, and the ‘Acceptance Criteria. 

2. How do you go about Sprint Planning?

Before we begin with the actual Sprint planning, Product Backlog refinement should be completed. My colleague, Shesha Rajkumar’s blog on Product Backlog Refinement, blog on Product Backlog Refinement takes you through the fundamentals of this process. 

The Product Backlog session ensures that the tasks are prioritized according to their priority level, value, work items, etc. Further, the Product Backlog Items are stacked on top of each other with a summary, a description of the user story, and the Definition of Done (DoD). Here, we decide what would constitute the completed story or “Done Done.” The Acceptance Criteria & Estimation are agreed upon using a familiar series; either the Fibonacci Series, T-Shirt Sizes, or even dog breeds are chosen to describe the complexity of the user story.

The Scrum Master facilitates the Sprint Planning and invites the Product Owner, Scrum Team, Security, Infrastructure team, and anyone involved in the delivery of increments.

As Sprint Planning is a time-boxed event, the product owner and team should come prepared for an in-depth question-and-answer on each user story.

Teams need to ask themselves the following questions to deliver and achieve the sprint goal:

3. Is the team comfortable with the stories, acceptance criteria, and estimation for the stories in Sprint Backlog?
4. Can the team achieve the product increment without fail?
5. How is the team planning to work and collaborate to deliver the increment?
6. Define specific sub-tasks like Design, Build/Code, Unit testing, Security, Peer/Code Review, & Deployment
7. Are there any critical dependencies to deliver the sprint goal?

3. What happens in Sprint Planning?
You need to follow the following steps in the sprint planning:

1. Understand the team’s capacity (Paid Time Off, Bank/National Holidays, etc.)
2. The Scrum team collaborates and discusses high-priority work items/issues based on the product backlog that can be mapped to the product goal or vision. These are talked about with the PO, and the acceptance criteria are agreed upon.
3. The development team can consolidate the queries, if any, by reviewing the prioritized backlog items and getting them clarified with the PO before the user story is pulled into the Sprint Backlog and updating the appropriate estimate to the story with the ‘Definition of Done,’ and the ‘Acceptance Criteria.
4. Highlight the user stories with dependency, slice the more powerful stories into smaller chunks, and ensure it delivers value to the user.
5. Discuss the Design, Architecture, Security, & anything which brings efficiency in the overall delivery and value to the user
6. Creating the tasks, subtasks like Design, Code, Code Review, Unit testing, System integration testing, Deployment
7. Provide accurate estimations based on the complexity of the user story and relative sizing.
8. Finally, capture the sprint goal with the product objectives and product vision.

4. Who should attend the sprint planning meeting?

Scrum team, namely,

• Development team
• Product Owner
• Scrum Master
• Any team part of delivery (Basis, Infrastructure, Security, support groups, etc.)

5. What are the artifacts of Sprint planning?

• Sprint Backlog – List of user stories selected for the sprint by the developers and a plan to deliver the increment & realize the sprint goal
• Sprint Goal – Provides direction to the team for WHY & WHAT has to be delivered and also establishes a sense of commitment, ownership, and purpose to solve the problem

Note: Sprint Planning is a time-boxed event. Additionally, it requires four hours for a two-week sprint & a maximum of eight hours for a four-week sprint. 

6. How to set Sprint Goals

Sprint goals should be clear, and we understand WHY and WHAT we are trying to deliver. Further, goal setting helps keep the team on track during the daily scrum/stand-up and ensures we stay within the goal.

The PO should help the development team include business or product objectives in the goals. However, the final goal will emerge in collaboration with the development team.

The Product Owner and development team should create goals to be unanimous on the sprint outcome. Set achievable goals; i.e., the plans ensure the quality of the deliverable, which is a part of the ‘Definition of Done.

Examples of unclear goals

1. Complete user story – 1, Bug – 6, user story – 18
2. Finish Epic – 5 
3. Fix all UAT/Prod Bugs
4. Complete the assigned task in Jira

Examples of clear goals

1. Improve the page load on Landing, Inventory, and sales orders within 10 secs
2. Add Date Filters to restrict the no. of transactions on sales orders (Latest Transaction) which improves the performance and provides flexibility to the user
3. Provide an option for the user to deliver instructions on orders “Avoid Calling,” “Leave with Security,” “Leave at Door,” or “Avoid Ringing DoorBell.”
4. Provide A-Z, Z-A sort functionality on the table to sort based on users’ choices

The Don’ts of Sprint Planning 

1. Avoid having generic sprint goals.
2. Further, velocity should not be the primary criterion for teams’ productivity; rather, it should be on value delivered to the user. Velocity is good for forecasting when there is no change in sprint duration, and team composition and similar functionality are being provided regularly
3. Stories should be worked by developers based on their respective skill sets, and Scrum Master & POs should not assign stories to developers
4. Developers should refrain from dependent or blocking user stories into the sprint backlog with unclear requirements or acceptance criteria.
5. Don’t change the sprint planning meeting scheduled time for every sprint
6. PO should refrain from demanding things that make his team uncomfortable. Alternatively, could I ask you to extend collaboration to ensure the team can deliver within reasonable constraints? 
7. The development team should avoid technical debts, provide a simple solution understand the requirement, and work closely with the PO to meet delivery goals.
8. Additionally, the Scrum Master/Product Owner should not estimate the user stories or defects/bugs on behalf of the development team
9. Developers should be quick to highlight training needs, if any, to deliver value and seek approval or guidance from the management.
10. Finally, developers should not provide unrealistic estimates which they can not deliver within a two or four-week sprint.

 

 

If you are interested in viewing similar content, you can visit our blog here. 

View our LinkedIn here.