Sprint Planning

[ps2id id=’WHAT’ target=”/A]

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 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 the incremental value to the product.

[ps2id id=’WHO’ target=”/A]

Who Should Participate in Sprint Planning Meeting

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

Generally the scrum team use to have the product backlog items estimated (story point) earlier during grooming season, if not or in case 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 initial list of tasks necessary to complete the committed PBI (Product Backlog items), with estimated effort in hours.

So who should participate in Sprint Planning meeting ?

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

In rare situation Stake Holders or other business sponsor can also attend by invitation from scrum team.


Lets take a quick look on Scrum roles and their responsibilities for Sprint Planing Meeting.

Scrum Master Responsibility for Sprint Planning Meeting

Before Sprint Planning Meeting

  • Have the Capacity Ready.
  • Try to have the team aware of the stories in priority”

During Sprint Planning Meeting

  • Marked the User Story as Committed for Sprint (if team mutually agreed to take that story ).
  • Make sure the stories committed have a Owner assigned. Try to have proper tasks created, all the tasks are assigned to team member, and all the task should have estimated effort hours
  • Update and validate capacity, Team member’s allocation , overloading etc. Avoid over allocation.
  • Stop to pick more stories, when the capacity is full or almost full.

After Sprint Planning Meeting

  • Verify Team allocation, day one burn down
  • Help team to plan and make the strategy to work on the committed stories.
  • Circulate sprint planning meeting notes.
  • If the team use a physical board, Collaboratively prepare the Scrum board.

Development Team Responsibility for Sprint Planning Meeting

Before Sprint Planning Meeting

  • Have the individual capacity updated
  • Get an Idea of the upcoming stories

During Sprint Planning Meeting

  • Negotiate and finalize the Sprint Goal.
  • Understand the story, Groom it (if not Groomed earlier), Estimate (SP) (if not estimated earlier)
  • Create Tasks on individual level, Assign to individual, Estimate hours for the task.
  • Update & validate available individual bandwidth.
  • Map Dependencies & Risks.

After Sprint Planning Meeting

  • Start Construction
  • Create Tasks (if not estimated during Sprint Planning)
  • Plan with in team member, to make the strategy to work on the committed stories.
  • May participate creating the Scrum board

Product Owner Responsibility for Sprint Planning Meeting

Before Sprint Planning Meeting

  • Plan the Sprint Goal
  • Prioritize the stories and organize the stories in order, in product backlog. Top stories in Backlog will pick first.
  • Prioritize User Story
  • Get the user stories Groomed and have them ready as per definition of Ready

During Sprint Planning Meeting

  • Create and provide the Sprint Goal. And Later negotiate with development team, to get it finalized
  • Clarify the doubts (if any) of stories (if required)
  • Navigate the stories in priority one by one to check if the team can commit, keeping the Sprint goal in mind .

After Sprint Planning Meeting

  • Verify the Sprint Goal is meeting from the stories committed by the scrum team
Scrum Roles Responsibility Before Sprint Planning
Sprint Planning
Scrum Roles Responsibility During Sprint Planning
Scrum Roles Responsibility After Sprint Planning
Sprint Planning

[ps2id id=’PRE’ target=”/A]

Prerequisite of effective Sprint Planning Meeting.

We already learned what is sprint planning and who can attend the meeting with what responsibility. Now before jump into start the sprint planning lets quickly have a look on the prerequisites of the sprint planning meeting.

Prerequisites of Sprint Planning Meeting

1.  Prioritized Backlog
We will talk about details on Product backlog on 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 owners activity, to utilize the sprint planning time with interest of every one, I always advice the product owner to prioritize the PBIs before sprint planning.
2.  Groomed Stories 
Many Agile team utilize the time  of sprint planning to groom PBIs. I have explained, why a team should groom their stories before sprint planning at the article of 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 details, estimated (Story Points), have the Risks and dependencies identified.
3. Definition Of Ready.
I will cover the details of Definition of Ready (DOR) in details in a separate article. Assuming you all know what is DOR.
Its a good practice to have a team DOR defined (subject to modify), The team always refer the definition of ready during sprint planning, before committing a story for the sprint. If a particular story in priority, and the product owner wants to have the story, part of the sprint to meet his this sprint goal, It has to pass through the DOR gate. DOR are the check list points to define the entry criteria of any user story if it is ready to commit or not.
4.  Planned Capacity
 Teams capacity to plan a sprint can be mesured by two different way,
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 to plan 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 .
Having the capacity defined, will help the team to commit 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.

[ps2id id=’TIME’ target=”/A]

How much time should Sprint Planning Meeting take

As per book, the sprint planning meeting should takes 2 x (number of weeks in sprint) Hours. Means if your sprint is 2 weeks your Sprint Planning meeting will take 4 Hours, if its is of 3 Weeks your Sprint Planning should be 6 hours and so on.

But in practical practice of 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 of managing works and time.

As per book, if it says we need 4 hours to complete our sprint planning for 2 week sprint, lets first try to understand what is expected from that 4 hours.

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

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

How ever in situations, teams may practice of having few of the activities prior to sprint planning, resulting less time consumption at sprint Planning. Lets have what are activities can be achieved earlier.

  • Product Owner to define the Sprint Goal
    • If Product Owner have a clear vision, he might have the goal defined earlier, Product Owner should not define the goal  based on committed story, that will become formality of having the sprint goal. If the Goal is already defined, PO only need to discuss them with the presence of Scrum team and make everyone aware of the expectations. by doing so the team will save time from sprint planning meeting.
  • 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 identify user stories to pick from product backlog
  • Groom the stories, Understand Requirement, 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 Groomed story as twice of velocity. That saves lots of time and resolve uncertainty during sprint planning.  
  • Estimate (story point)
    • Its always better to have story points estimated for all the groomed stories, you can estimate the user story during grooming, and can have a check point of your definition of ready. And yes it will definitely save time from sprint planning meeting
  • Plan you capacity (If capacity not measured as velocity)
    • If Capacity not measured based on velocity, that means it has to be calculated based on hours. So if the development team have the capacity planned before sprint planning. its will save time.
  • Break down into tasks, assign tasks, estimate Task hours
    • This activity will do during sprint planning meeting. Many team does this activity partially or fully after sprint planning. I suggest to have this activity during sprint planning.

So how much time a sprint planning should take, its depends upon your practice. It can take 1 to 4 hours for a 2 Week Sprint. The teams I coach, after 2 to three months of practice they come down to 1 to 1.5 Hours of sprint planning for 2 weeks sprint. 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 if 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.

[ps2id id=’STEP’ target=”/A]

Step by step walk through of Sprint Planning Meeting

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

Refer the below picture of a scrum work flow. As Agile is a framework, there may be slight difference on the work flow, you are working or may work. However basic structure remains same.  In this work flow, you will be able to identify ongoing activity and prerequisites for sprint planning.


Now from the below picture lets find out where are those prerequisites stands, for the sprint planning meeting with in 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.

Sprint Planning

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

Those are

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

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

Sprint Planning

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


The Sprint Planning meeting generally have two main areas,

  1. Defining the sprint Goal

Sprint Goal is a target or objective for a sprint. Which can be achieved by implementing 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 is better to be measurable. The selection of the Product backlog Item from Product Backlog is depend upon the Goal. Sprint Goal should be short, 2 to 3 sentence.

Sprint Planning

2. Defining the scope of Sprint backlog

The Second half of the sprint planning is spent for defining the sprint scope, keeping in mind the sprint goal. lets see the step by step activity below to identify the sprint goal.

Sprint Planning

Selecting the Product backlog item from product backlog

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

Product Owner selects the PBI from backlog with teams consent.

Make Sure the PBI is ready to commit

Ideally the picked up PBI are in groomed state, where the dependencies are mapped, and communicated to cross functional team, Risks are identified, Story point estimated. And requirements are mutually understood by development team. And the PBI is in a position to meets the definition of ready.

However, there are possibilities, that product owner identified some stories that needs to be done by the upcoming sprint. And that PBI yet to be groomed and needs meet the Definition of ready to be committed for a sprint.

In that case, The team groom that specific PBI, Check their dependencies, Risks, 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.

Sprint Planning

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 needs to be done, like development, Testing, code review, QA deployment etc. create as many task you think will be easy to manage.

There are debates on how many tasks we should create, many agile practice says, keep it simple by just having 3 tasks, 1. Analysis, 2.Development, Testing.

Where many agile practices says, keep the task as much you want to have the work transparent and visible.

Sprint Planning

Task Assignment

Next, the team collaboratively assign the tasks to development team member. A self organized team can assign the tasks to team selves. Its best to have all the team member are of same technical expertise level, but in practical situation its 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 keeps an eye on the capacity, to avoid any kind of over allocation, that may risk the sprint with unfinished work.

Sprint Planning

Task Estimation

Once the task assignment is done, its time to estimate the task. As each team member my have different skill set and experience level, its always better to have the task estimation after assignment to individual.

This estimation is effort hours.

If the team is new its advisable to have tasks hours to keep with in 8 to 12 hours. This helps the team to analyse in details 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 member. That will be useful during your next PBI commitment. If you need to understand details of capacity planning. Please refer our another article on understanding capacity Planning.


Agile is a framework, the above mentioned was is one of the best practice of running scrum, many team have practice of not estimating or creating sub-tasks during sprint planning, rather the do it after sprint planning, may be during next few days. And they are doing perfectly fine.

But they may not be able to plan based on capacity, and may have fluctuations on Scope creep and commitment reliability.

I always suggest to have the tasking during sprint planning, so that you can utilize you capacity in optimum. You will able to produce yourself a good and healthy team during metrics reports at higher level.

Commit to the sprint

And then finally add the story to 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 you goal how much its covered from the committed sprint scope. Now you can make minor modification on 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 story to fill up the gap. To understand more about types of Product backlog items or User story. Please read the article on Understating User story.

There are other situations like, in case the team ratio is 70% developer and 30% tester, where during planning, the tester’s capacity is filled after certain PBI commitment. In that case also, the developers can pick technical spikes or utilize their capacity on testing tasks.

Refer below the full diagram of Sprint planning.

Sprint Planning

[ps2id id=’DELIVERABLE’ target=”/A]

Expected deliverable of Sprint Planning Meeting

Sprint Planning meeting have two parts, first half the team define the Sprint goal, and then at the second half team define the Sprint backlog , the scope of the sprint to meet the goal.

So the two deliverable from Sprint Planning meetings are

  1. Sprint Goal
  2. Sprint Backlog

Lets find out little more details on these two artifacts.

Sprint Goal

What is Sprint Goal

Sprint Goal is a target or objective for a sprint. Which can be achieved by implementing 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 is better to be measurable. The selection of the Product backlog Item from Product Backlog is depend upon the Goal. Sprint Goal should be short, 2 to 3 sentence.

Benefits of Sprint Goal

The Business Sponsor or stakeholders, prefer to get a vision from a birds eye view, rather than details story level information. The Sprint goal is always better to highlight what the team is doing. And at top level, if they are managing multiple teams, 2 to 3 line summary from each team is a useful information.

The team commit to a goal and associated PBIs, that helps the team to execute the sprint with a specific vision.


During Sprint review, product owner, or stakeholders, verify the product increment by comparing the Goal and how much is achieved. That’s defined the success of the sprint.


1. Implement the Login screen functionality

2. Implement the functionality to enable Credit card payment on shopping cart.


Sprint Backlog

Sprint Backlog is one of the artifacts of Scrum. and its get generated on every sprint planning, and is a active for the sprint duration. After the sprint ends this artifacts gets closed and only refer to reporting purpose.

Sprint backlog contains Product backlog items committed for a sprint. means if you are doing a 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 contains User stories, Bugs, Spikes etc.  The Sprint backlog is virtual list of bunch of product backlog item, you may able to see it as a list of items in your ALM tool. During the beginning of 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). Now a days 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 mixed up Burn-down chart, its not a part of sprint backlog, its a part of your sprint.

Don’t mixed up with Scrum Board or Sprint Board with Sprint backlog. This Boards are visual representation of the sprint backlog Items with their status.

Sprint backlog have, 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 are Done.

♦ Total estimated effort hours (Tasks estimated hours for all the tasks of all the stories)

♦ Or Total remaining estimated effort hour

[ps2id id=’REPORT’ target=”/A]

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, Stake holders, 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 when ever the feels like. 
  4. Capacity Utilization
    • Give a capacity summary
    • Optionally you can also attach the details capacity utilization, with Team members name, Story id and Task Hours
  5. Commitment summary
    • Give a Summary of your commitment
  6. Commitment Story Summary
    • Mention the story details those were committed.

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

[ps2id id=’BENEFIT’ target=”/A]

Benefits of Sprint Planning Meeting

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

I am summarizing the high level benefits of sprint planning meeting, here below.

Goal Visibility.

To work on something, we need a target, a goal to work on. The scrum team gets that target as sprint goal for a limited time box or for the sprint. Having a goal for the team gives them the visibility why we are working on this stories or product backlog Item.

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 the Tasks assigned to individual team member. This gives a great visibility , and transparency on individual level as well as on team level to focus, plan and execute the work items.

Optimal usage of capacity

Scrum Team have a limited capacity for each iteration/Sprint/time box. To use the capacity in most optimized way sprint planning meeting facilitate the distribution of tasks to individual. which helps the team to avoid bandwidth wastage and over loading. Resulting high performance and quality product.

Improve Team Collaboration

And finally this Sprint planning meeting involves all the scrum team members, along with cross functional team and Stake holders. That improves team collaboration and a healthy productive environment.

Improve Commitment Reliability

Sprint Planning helps the team to commit based on their capacity, resulting the team save themselves from over commitment. That in result improve their commitment reliability.

Control Scope Creep

Sprint Planning helps the team to commit based on their capacity, resulting the team save themselves from Under commitment. And so the team don’t need to add additional PBIs in their sprint scope, and the team remain on the commitment of initial scope definition.

Sprint Planning Benefits

[ps2id id=’VIDEO’ target=”/A]

Additional Videos with real life examples using ALM Tools.

Understanding Sprint Planning Meeting.

 Sprint Planning Meeting in Jira

Sprint Planning Meeting in Rally

Hope this page was able to provide the information you were looking for, In case we missed something, feel free to leave your comments, feedback and suggestions, at bottom of the page’s comment section.

Author(s) of this article


  1. I am really impressed with your writing talents as well as with the layout to your weblog. Is this a paid subject matter or did you modify it your self? Either way stay up the nice high quality writing, it’s rare to look a great blog like this one these days..

Leave a Reply