Sprint Planning

What is Sprint Planning

In Scrum, we have multiple time boxes called Sprints or iterations. In each Sprint bunch of functionalities in the form of stories are implemented to make incremental enhancements to the product under development. The Sprint Planning meeting is the kickoff meeting for each Sprint. This meeting helps set the context of the sprint by scoping up the product owner goals for this sprint. It also prescribes the priority for the stories, based on available bandwidth/capacity to meet the goal and deliver incremental value to the product.

Who Should Participate in Sprint Planning Meeting

Scrum Master facilitates the Sprint Planning meeting, during the sprint planning meeting, the Product Owner and the Development Team agree to the Sprint Goal and negotiate which item from the product backlog will be committed to the sprint backlog in Understanding Scrum.

Generally, the scrum team use to have the product backlog items estimated (story point) earlier during grooming season, if not, or in case the product owner wants to have some non groomed story to be included in the sprint, the development team can groom and estimate the story during sprint planning.

Also in this meeting, the Team will come up with an initial list of tasks necessary to complete the committed PBI (Product Backlog items), with estimated effort in hours.

So who should participate in the Sprint Planning meeting?

1. Product Owner
2. Scrum Master
   &
3. Development Team

In rare situations Stake Holders or other businesses, or sponsors can also attend by invitation from the scrum team.

Let’s take a quick look at Scrum roles and their responsibilities for Sprint Planning Meeting.

Scrum Master Responsibility for Sprint Planning Meeting

Development Team Responsibility for Sprint Planning Meeting

Product Owner Responsibility for Sprint Planning Meeting

Prerequisite of effective Sprint Planning Meeting.

We already learned what is sprint planning and who can attend the meeting with what responsibility. Now before jumping in to start the sprint planning let’s quickly have a look at the prerequisites of the sprint planning meeting.

Prerequisites of Sprint Planning Meeting1.  Prioritized BacklogWe will talk about details on Product backlog in some other article. For sprint planning, we need to have a product backlog, where the Product Backlog items (PBI) are arranged in priority. The product owner may do the prioritization during sprint planning, but the prioritization is mainly a product owner’s activity, to utilize the sprint planning time with the interest of everyone, I always advise the product owner to prioritize the PBIs before sprint planning.

2.  Groomed Stories Many Agile teams utilize the time of sprint planning to groom PBIs. I have explained, why a team should groom their stories before sprint planning in the article on backlog grooming. So I always coach the agile team to groom the product backlog well in advance of sprint planning. to have the PBIs well elaborated in detail, estimated (Story Points), have the Risks and dependencies identified

.3. Definition Of Ready.I will cover the details of the Definition of Ready (DOR) in detail in a separate article. Assuming you all know what is DOR. It’s a good practice to have a team DOR defined (subject to modification), The team always refers to the definition of ready during sprint planning, before committing a story for the sprint. If a particular story is a priority, and the product owner wants to have the story, as part of the sprint to meet this sprint goal, It has to pass through the DOR gate. DOR is the checklist point to define the entry criteria of any user story if it is ready to commit or not.

.4.  Planned Capacity Team’s capacity to plan a sprint can be measured in two different ways, 1. Story Points (Average Velocity of last sprints)It can be used for a stable team, with no change in team composition, No variation of team members’ allocation sharing between projects. 2. Hours (Available bandwidth of the team for the upcoming sprint duration)I always suggest planning your capacity based on Hours, keeping in mind the team member’s allocation %, Vacation, Holidays, time for Scrum Meetings, etc., and get the available capacity for the sprint. To Learn details of Capacity Planning visit the link – of Capacity Planning.

capacity defined, will help the team to commit the right amount of PBI from product backlog to sprint backlog. Will learn details about the sprint planning and using the defined capacity later in this article. How much time should Sprint Planning Meeting takes per book, the sprint planning meeting should take 2 x (number of weeks in a sprint) Hours. This means if your sprint is 2 weeks your Sprint Planning meeting will take 4 hours, if it is of 3 Weeks your Sprint Planning should be 6 hours, and so on.

But in practical practice, each team is different, We are maturing our agile practice and improving the way we started running our agile framework. So the time the sprint planning takes depends upon our practice and our agility in managing work and time.

As per the book, if it says we need 4 hours to complete our sprint planning for the 2-week sprint, let’s first try to understand what is expected

1. Product Owner to define the Sprint Goal, and get it Negotiated with the development team.
2. Identify Stories to meet the goal, or create new stories to meet the goal
3. Groom the stories, Understand Requirements, identify dependencies, identify risks
4. Estimate (story point)
5. Plan team capacity (If capacity is not measured as velocity)
6. Break down into tasks, assign tasks, estimate Task hours

And if you really doing all those activities, it will take that much time.

However, in some situations, teams may practice having few of the activities prior to sprint planning, resulting in less time consumption at Sprint Planning. Let’s have what are activities can be achieved earlier.

• Product Owner to define the Sprint Goal
  • If the Product Owner has a clear vision, he might have the goal defined earlier, Product Owner should not define the goal based on the committed story, that will become a formality of having the sprint goal. If the Goal is already defined, PO only needs to discuss them with the presence of the Scrum team and make everyone aware of the expectations. by doing so the team will save time from sprint planning meetings.
• Identify Stories to meet the goal, or create new stories to meet the goal
  • Prioritization is important, if the PO keep the backlog prioritized based on expected sprint goal, associated risks, and business demand, The team can save time on identifying user stories to pick from the product backlog
• Groom the stories, Understand Requirements, identify dependencies, identify risks
  • Many teams have, and I personally advise to have grooming once or twice a week, to have a healthy backlog, by having the Groomed story as twice of velocity. That saves lots of time and resolves uncertainty during sprint planning.  
• Estimate (story point)
  • It is always better to have story points estimated for all the groomed stories, you can estimate the user story during grooming and can have a checkpoint of your definition of ready. And yes it will definitely save time from the sprint planning meeting
• Plan your capacity (If capacity is not measured as velocity)
  • If Capacity is not measured based on velocity, that means it has to be calculated based on hours. So if the development team has the capacity planned before sprint planning. It will save time.
• Break down into tasks, assign tasks, estimate Task hours
  • This activity will do during the sprint planning meeting. Many teams do this activity partially or fully after sprint planning. I suggest having this activity during sprint planning.

So how much time sprint planning should take, depends upon your practice. It can take 1 to 4 hours for a 2 Week Sprint. For the teams, I coach, after 2 to three months of practice comes down to 1 to 1.5 Hours of sprint planning for 2 weeks sprints. Remember the earlier section? Prerequisites? Yes If you want to optimize the time of sprint planning, you need to have the prerequisites ready.

Now if you are thinking of all those activities we are doing before sprint planning, what we will be doing during sprint planning. That we will learn in this next section.

Step-by-step walkthrough of Sprint Planning Meeting

Yes, sprint planning is one of the core ceremonies to plan your sprint scope. Before we jump into granular details of sprint planning let’s first try to understand where the sprint planning ceremony is placed in scrum workflow.

Now from the below picture let’s find out where those prerequisites stand, for the sprint planning meeting within scrum workflow.

The prerequisites of

• Definition of Done
• Groomed and Prioritized backlog
• Planned Capacity from capacity planning

is shown providing inputs to the sprint planning

Before we jump into the step-by-step activity we do in sprint planning, let’s have a quick look at the outcome of the sprint planning meeting. Refer to the picture below to understand the output of the sprint planning meeting.

Those are

1. A Sprint Goal.
2. A Sprint backlog.

We will talk about the details of this outcome, later in this article under the “Expected deliverable of Sprint Planning Meeting” section.

Let’s now talk about what we do within the sprint planning meeting. Step by Step each activity we will talk about, each, and then will see in a diagram how all the activities are linked together.

The Sprint Planning meeting generally has two main areas,

1. Defining the sprint Goal

Sprint Goal is a target or objective for a sprint. This can be achieved by implementing a set of functionality ( PBI, user stories, bug fixing, etc.).  The Development team and Product owner negotiate and collaboratively set up a goal for a specific sprint or iteration. The Goals are better to be measurable. The selection of the Product backlog Item from the Product Backlog is depend upon the Goal. Sprint Goal should be short, 2 to 3 sentences.

2. Defining the scope of Sprint backlog
   The Second half of the sprint planning is spent defining the sprint scope, keeping in mind the sprint goal.
   let’s see the step-by-step activity below to identify the sprint goal.

Selecting the Product backlog item from the product backlog

The first step to defining the sprint goal is to have a sprint backlog, the team selects the first product backlog item from the prioritized backlog. The selection of this story/PBI is a part of sprint goal fulfillment.

The Product Owner selects the PBI from the backlog with the team’s consent

Make Sure the PBI is ready to commit

Ideally, the picked-up PBI is in the groomed state, where the dependencies are mapped, and communicated to the cross-functional team, Risks are identified, Story point is estimated. And requirements are mutually understood by the development team. And the PBI is in a position to meet the definition of ready. However, there are possibilities, that the product owner identified some stories that need to be done by the upcoming sprint. And that PBI is yet to be groomed and needs to meet the Definition of ready to be committed for a sprint. In that case, The team groom that specific PBI, Check their dependencies, Risks, and feasibility, and estimate its relative size in Story point during sprint planning. If the PBI was already groomed and estimated, teams move to the next step.

Task Break Out

Once the picked-up PBI meets the definition of ready, the team starts working on task break out. the development team creates multiple sub-tasks against the PBI, keeping all possible technical works that need to be done, like development, testing, code review, QA deployment, etc. create as many tasks you think will be easy to manage. There are debates on how many tasks we should create, many agile practices say, to keep it simple by just having 3 tasks, 1. Analysis, 2. Development, Testing. Where many agile practices say, keep the task as much you want to have the work transparent and visible.

Task Assignment

Next, the team collaboratively assigns the tasks to a development team member. A self-organized team can assign the tasks to the team selves. It’s best to have all the team members be of the same technical expertise level but in practical situations, it’s very rare to find a time like that. So the team finds which task is suitable for which team members’ skill set and expertise level. And assign it accordingly. The Scrum master and the team always keep an eye on the capacity, to avoid any kind of over-allocation, that may risk the sprint with unfinished work.

Task Estimation

Once the task assignment is done, it’s time to estimate the task. As each team member may have a different skill set and experience level, it’s always better to have the task estimation after assignment to an individual. This estimation is effort hours. If the team is new it’s advisable to have task hours to keep within 8 to 12 hours. This helps the team to analyze in detail and give better transparency. The Team can create new sub-tasks, or split existing sub-tasks into one or more. Remember to update the capacity tracker with the hours and team members. That will be useful during your next PBI commitment. If you need to understand the details of capacity planning. Please refer our other article on sprint planning

Note

Agile is a framework, the above-mentioned was is one of the best practices of running scrum, many teams have a practice of not estimating or creating sub-tasks during sprint planning, rather do it after sprint planning, maybe during the next few days. And they are doing perfectly fine. But they may not be able to plan based on capacity and may have fluctuations in Scope creep and commitment reliability. I always suggest having the tasking during sprint planning, so that you can utilize your capacity at optimum. You will be able to produce a good and healthy team during metrics reports at a higher level in Understanding Scrum.

Commit to the sprint
And then finally add the story to the sprint backlog.
and proceed to the product backlog to pick the next PBI to plan

And continue this step till the time-planned capacity is fully utilized. It may be possible there are stories left in the backlog and your capacity is fully utilized, and that’s normal. Check your goal and how much it’s covered from the committed sprint scope.
Now you can make minor modifications to the goal to represent the commitment and Goal in sync. Similarly, it may be possible that all the stories are committed and still there are some capacity remains.
The team can pick some intangible PBI or technical spikes or non-user stories to fill up the gap. To understand more about types of Product backlog items or user stories. Please read the article on Understating User story.
There are other situations, in case the team ratio is 70% developer and 30% tester, where during planning, the tester’s capacity is filled after a certain PBI commitment. In that case, also, the developers can pick technical spikes or utilize their capacity on testing tasks.

Refer below to the full diagram of Sprint planning.

The expected deliverable of the Sprint Planning Meeting

Sprint Planning meeting has two parts, first, half of the team defines the Spring
the goal, and then in the second half team defines the Sprint backlog, the scope of the sprint to meet the goal.
So the two deliverables from Sprint Planning meetings are

• Sprint Goal
• Sprint Backlog

Let’s find out a little more details about these two artifacts sprint planning

What is Sprint Goal
A sprint planning Goal is a target or objective for a sprint. This can be achieved by implementing a set of functionality ( PBI, user stories, bug fixing, etc.). The Development team and Product owner negotiate and collaboratively set up a goal for a specific sprint or iteration. The Goals are better be measurable. The selection of the Product Backlog Item from the Product Backlog is depends upon the Goal. Sprint Goal should be short, 2 to 3 sentences.

Benefits of Sprint Goal
The Business Sponsor or stakeholders, prefer to get a vision from a birds-ey view, rather than details story-level information. The Sprint Goal is always better to highlight what the team is doing. At the top level, if they are managing multiple teams, a 2 to 3-line summary from each team is a piece of useful information.
The team commits to a goal and associated PBIs, that help the team to execute the sprint with a specific vision.
Importance
During Sprint review, the product owner, or stakeholders, verify the product increment by comparing the Goal and how much is achieved. That defined the success of the sprint.
Example

1. Implement the Login screen functionality
2. Implement the functionality to enable Credit card payment on the shopping cart. Sprint Backlog

Sprint Backlog is one of the artifacts of Scrum. and it gets generated on every sprint planning and is active for the sprint duration. After the sprint ends this artifact gets closed and only refers to reporting purpose.
Sprint backlog contains Product backlog items committed for a sprint. means if you are doing sprint planning for Sprint# 12, all the product backlog items committed for Sprint#12 will be under sprint backlog #12.
Each Sprint will have a sprint backlog, and it may contain User Stories, Bugs, Spikes, etc. The sprint backlog is a virtual list of a bunch of product backlog items, you may be able to see it as a list of items in your ALM tool.
During the beginning of the Agile era, Agile teams used to maintain one big excel for product backlog and independent excel for sprint backlog (Many Agile practices still follow this excel). Nowadays the ALM tools like Rally, Jira, TFS, Version one, etc have made our life easy to manage all those numerous sprint backlogs easy to manage and track.
Don’t mix up the Burn-down chart, it’s not a part of the sprint backlog, it’s a part of your sprint.
Don’t mix up with Scrum Board or Sprint Board with Sprint backlog. These Boards are visual representations of the sprint backlog Items with their status.
Sprint backlog has Sprint backlog items. You can calculate aggregated values like

♦ Number of Items
♦ Total Backlog story points (size of the backlog, calculated by total story points of all the Items).
♦ Total backlog story points at each stage, for example, How much SP in ToDo, how much in Analysis, how much in Development, how much in Testing, and home much is Done.
♦ Total estimated effort hours (Tasks estimated hours for all the tasks of all the stories)
♦ Or Total remaining estimated effort hour

Summary report of Sprint Planning

Once the Sprint Planning is over, the Scrum Master sends a Sprint Planning Notes to everyone including the Scrum team and other interested members like Stakeholders, Project Managers, Business Sponsors, etc.

The Areas you can cover in a sprint planning notes are as below.

1. Sprint Goal
   • Highlight the agreed Sprint Goal
2. Sprint Duration
   • Mention the Sprint Duration in Days
   • Sprint Start Date
   • Sprint End Date
3. Sprint Schedule
   • Mention all the sprint ceremonies like Demo/Review, Retrospective schedule
   • Attach the retrospective links (if possible), so that people can start their ideas whenever they feel like it. 
4. Capacity Utilization
   • Give a capacity summary
   • Optionally you can also attach the details of capacity utilization, with the Team member’s name, Story id, and Task Hours
5. Commitment summary
   • Give a Summary of your commitment
6. Commitment Story Summary
   • Mention the story details that were committed.

Refer to the image below, and click to see it on a larger size, You can refer to the image to create your own Summary report as per your need. The data provided in the report are just an example only.

Benefits of Sprint Planning Meeting

Sprint Planning is one of the core ceremonies of Scrum. If you have gone through this far of the article you might have realized the importance of Sprint planning meeting.

I am summarizing the high-level benefits of the sprint planning meetings, here below.
Goal Visibility.
To work on something, we need a target, a goal to work on.
The scrum team gets that target as a sprint goal for a limited time
box or for the sprint. Having a goal for the team gives them the visibility of why we are working on these stories or product backlog Items.

Scope Visibility.
Scope (The committed User Story or product backlog item)
is very important to define for a limited duration of work, As we already have the goal.
The definitions of the scope give the team what to work on to meet the goal.
Having a clearly defined scope helps the team to focus on their action item, plan of execution, and on-time completion

Task Discovery
On Granular level execution of scope, Task break down helps to pin down the activities and plan individual level
To-Dos. Sprint Planning meeting helps the team to have the necessary ground level tasks against each PBI or User story, Have the Tasks estimated in hours and theTasks assigned to an individual team member. This gives great visibility, and transparency on an individual level as
well as on the team level to focus, plan and execute the work items.

Optimal usage of capacity
Scrum Team has a limited capacity for each iteration/sprint/time box. To use the capacity in the most optimized way sprint planning
meetings facilitate the distribution of tasks to individuals. which helps the team to avoid bandwidth wastage and overloading. Resulting in
high performance and quality products.

Improve Team Collaboration
And finally, this Sprint planning meeting involves all the scrum team members, along with cross-functional
team and Stakeholders. That improves team collaboration and a healthy productive environment.

Improve Commitment Reliability
Sprint Planning helps the team to commit based on their capacity, resulting in the team saving themselves from over-commitment. That is a result that improves their commitment reliability.

Control Scope Creep
Sprint Planning helps the team to commit based on their capacity, resulting in the team saving themselves from Under commitment. And so the team doesn’t need to add additional PBIs in their sprint scope, and the team remains on the commitment of initial scope definition.