Before we start the Sprint, we need to perform the Sprint planning. In this article, we are going to learn Sprint Planning in 7 easy steps. It starts from a few key steps which include making the Product backlog properly created, conducting the sprint planning meeting and starting the sprint.
Step 1: Product Roadmap
First, we need to have the high-level vision of the Product. Now the features we are planning to build should continue the vision of our Product at the high level. We may not have a complete understanding of the final deliverables but we should know the problems which we are going to solve. It is the responsibility of the Product Manager to keep the high-level Product view always for the team.
Step 2: The Product Backlog and User Stories
Instead of immediately jumping into the task in hand, the team should know what we are going to achieve and how my task in-hand work is going to create an impact on the final deliverables. Therefore, it is important to priorities the Product backlog first. We should keep these things in mind,
i. Whether the most important item is present at the top
ii. Whether the user stories are clear and fully-formed so the team can start working on right away
iii. Whether all the details are updated in context for large Product milestones and complexity
Therefore, we need to categories the issues so that the team will identify the work each task involves. We can divide the task in several sub-tasks and identify the connectivity of the relevant tasks and stories together. In this way, we can find out the Bottle-neck of the tasks and we can form a strategy for the mitigation.
The User Stories: Next, we need to write the User stories of each task defined in the backlog list. Here we will take the help of the Product team, Business Analyst and Product Manager to all relevant information. It will include a proper description, priority, status, estimated time, and even acceptance criteria. Here we write that as a User, I want to do this so that a certain outcome can be achieved. It will help the Development team to understand the requirement and based on it, they prepare the unit test cases.
Based on the importance, workload and complexity of the User stories, we assign the points to them. It can be any unit like S, M, L, XL or 1,2,4,8. The Unit Testing of the code and code review of the teammates also included in the task of the team. We also draw the Mock-ups or prototypes for the UI/UX team to provide them with the clarity. The User story also helps the testing team to identify the success criteria and the end outcomes. They also write down the test cases and test plan based on the User stories. We put all the Story points into the Agile board which is also known as Scrumban board. In the sprints, we update the status of the user stories based on the performance. The User stories will start its journey in this way:
Backlog -> To Do -> In Progress -> Testing -> Completed.
Step 3: The Sprint Planning Meeting
Just like the backlog prioritization, before starting the sprint, we need to identify the outcome we are trying to accomplish and how we are working to achieve it. The goal should be realistic based on the scope of task and the team size. It is the job of the Product Manager to plan for the sprint goal and set the agenda.
- Product Owner: Sets the goals, priorities, and explains context for this sprint based on the demand of the client. He/she ensures backlog items are properly groomed. Product Manager discusses all customer team requests and communicate back to customer on latest releases and client’s expectation.
- Scrum master: Facilitates the meeting by setting the agenda. He/she conducts the daily scrums, and understands breakdown of each step of the sprint process via KPIs/metrics. PM also identifies bottlenecks in the process and recommends how to debottleneck. PM sets the delivery goal at the end of each sprint.
- Agile team members: The team can ask questions and share views on the sprint backlog. The help of the domain or technical expert can be taken. The team can also discuss the User stories and can divide into technical tasks if needed. The definition of completion and the acceptance criteria can also be clarified in the meeting. Team also discussed if there any requirement of the specialist or special skillset or special kind of hardware/software in the work.
Finally, the team discuss the capacity for the sprint. It can be determined based on the availability of the team members, past experience (downtime, overhead etc.), timelines shared with the clients. Once the Sprint starts we can check the performance in the form of various graphs like Burn Down Chart, Velocity chart, cumulative flow chart etc.
Step 4: A Final Commitment
Once all the aspects of the planning complete, the verbal commitments from the team members required in the high spirit. Because at the end of the day it will the team who will perform and delivers the outcome. It is important to have a common ground in the team and work as a single unit. Therefore, the personal commitment of team members can play a vital role in the performance of the Sprint.
Step 5: Daily Scrums
It is a meeting for Team, not by Scrum Master or Product Manager. It is not just a status update meeting but a medium to interact with your team. Product Manager should let the team to express themselves in constructive manner. It helps to coordinate among the team members and also brings transparency in the team. The meeting should be completed in approx. 15 mins. If some discussion point goes beyond the time, then we discuss it off-line. Basically, the team members discuss the three basic questions:
1. What tasks have been completed?
2. What we are planning to do today?
3. What are the impediments for the tasks?
Product Manager helps the team to achieve its goals decided for the day. We also check the Burndown chart, and make a strategy for today. We also rearrange the tasks, if needed. Once a task competes then we update its position in the Scrumban board.
Step 6: Sprint Retrospective
The success of the Sprint is measured by sprint review meetings. It helps us to identify whether we are progressing in the right direction. However, we don’t always measure the success based on the stories we have completed. We also measure it against the acceptance of the client. If the client or stakeholders are not satisfied, then the sprint is not successful. Similarly, if we have not learned anything from the Sprint then all the goals are not met.
Step 7: Plan, Do, Check and Repeat
Once we have completed the Sprint Review, we again priorities the Product Backlog and start the next Sprint again. Here we have to again follow all the steps to conduct the sprint. The purpose of this exercise is to align each sprint with the final outcome of the Product and learn from the past sprints.
28/11/2022, 10.00 AM