How to Run a Sprint Planning Meeting (the Way I Like It)

This is a sample agenda for a sprint planning meeting. Depending on your context you will have to change the details, just make sure the outcomes stay the same.


Meeting purpose: Plan and prepare for the upcoming sprint
Meeting duration: ca. 1 hour for a 2 week sprint (it will be less if you’re an experienced team and know your domain well)

Scrum process

Part 1:


1. Intro & set the scene


Remind everyone that the purpose of the meeting is to plan the work for the next sprint.
Remind everyone of the sprint duration and demo date.


Share the desired meeting outcome:
– A sprint goal
– A sprint backlog including tasks

Share the planned agenda:

  • Define the sprint goal
  • Decide how much to chew off
  • Decide which stories to do this sprint
  • Create tasks for stories


2. Define the Sprint goal


Come up with a sprint goal: The purpose of having a goal is to be able to select user stories that support the goal, i.e. help you work towards something bigger than just delivering a collection of stories or unrelated features. It’s also really useful to assess at the end of the sprint whether you have been successful or not. Success is achieving the sprint goal, not just delivering all the stories you had planned to get done.


Examples could be:

  • Build edit delivery feature
  • Make the app hotter!
  • Demo advanced property search” (It’s okay to have a goal that is to collect feedback through a demo/prototype)
  • Fix push notifications and improve motors search” (One goal is better but if it is way too small it’s okay to have a dual goal. Just make sure you don’t end up with just a collection of unrelated user stories)

3. Decide how much to chew off


If you are using story points or count the number of stories delivered as a measure of velocity it’s a good idea to decide on a target velocity next. Base that decision on looking at a combination of past velocity, people’s availability (any holidays?) and just plain gut feeling.


Make sure you take past data into consideration, not just wishful thinking about how much you feel you “should” get done. This is also the reason why I like to discuss target velocity before choosing stories for the sprint: It is all too easy to get carried away with enthusiasm and optimism.


If you don’t have any data yet, don’t worry – just go by gut feeling and start collecting data now.


4. Decide which stories to do in this sprint


Take your product backlog and discuss for each candidate story what it means, what you’re trying to achieve and what success looks like. Do this for all the stories you think you might be able to schedule into the sprint.


Choosing which stories to consider for your sprint is mainly determined by the sprint goal. Other considerations are:


  • What if we can do more than just the stories that support the goal?
    You could have a secondary goal (“Fix push notifications and improve motors search”) but make sure these are prioritised against each other. Or you could “fill” with bug fixes, enhancements and smaller, not necessarily related requests. Make sure to communicate that these are less important though than things that support the sprint goal and will get dropped if the goal is in danger.
  • What if there’s stuff we really want to do such as re-paying some technical debt?
    I like agreeing on one or two of such items for each sprint. I have found ca. 20% of a sprint’s work dedicated to the team’s wishes to be a good thing.
  • What about high risk items?
    It sometimes makes sense to prioritise a risky story higher to just learn, gather knowledge and be able to plan. Early prototypes for hairy features are a good idea.


What it comes down to is to have a discussion between the team with their technical expertise and the Product Owner as the representative of end users and stakeholders and to decide together what you want to do during the next couple of weeks.


Also, make sure not to “fill up” your entire sprint with planned work but to leave some room for unexpected opportunities or complexities.


Once you have decided which stories to aim for during the next sprint, move on to part 2.


Part 2:


5. Task planning


I like planning individual tasks for each user story and to make work visible at a granular level. This makes it easier for people to collaborate around user stories and to help each other reach a shared goal.


As an example for the user story “As a photographer I want to make some of my albums private so that no one else can see them” we identified the following tasks:


If you find it hard to make tasks ask yourself how you would get started. And what you would do next? And then? You’ll find you can come up with quite a lot of useful tasks that need to be done.


Try to keep tasks to less than a full day’s work so that stuff moves through on a daily basis and there is a sense of progress and opportunity for collaboration during the daily standup. Also, try to split them in a way so that in theory different people could do different tasks.


Remember that you don’t need to get the tasks right upfront: It’s perfectly fair to add new tasks to a story or to delete tasks that are no longer needed during the sprint.


And don’t assign tasks upfront! It will just make you wait for each other and cheat you for opportunities to collaborate and help each other.


Part 3: Set up your visual workspace


This is the outcome of your sprint planning meeting: A visual workspace with a list of user stories and associated tasks.


Here’s an example:

visual workspace


If you aren’t co-located you can of course achieve the same in Jira or some other tool. I really like the tactile and highly visible nature of the post-it note board though, so if you have the option I’d definitely use one of these.


Sandy Mamoli
  • Sri

    Very good article. Thanks to Author.

    April 13, 2016 at 10:15 pm
  • Jeffrey Milton

    Great article – is the process of changing over to Agile, and this wakes it clear for my team.

    April 24, 2016 at 2:59 am
  • Jasdev

    with respect to task planning – my team resists adding tasks and estimates to user stories. how can i convince them to add tasks to user stories that they are working on? Also not adding tasks makes it difficult to track progress on burn-down.

    April 30, 2016 at 1:31 am
  • K.Wood

    Hi, good article.
    I find its difficult to get our sprint planning meeting down from about 3 / 4 hours.

    The acceptance criteria is all pre-written but the developers want to read through each task entirely, discuss the technical challenges and then rate it. If theres a big difference in ratings we then discuss this.

    We work on a 2 week sprint so it takes up a great deal of everyones time.

    Do you have any tips on how to try and get it down to around 1 hour? Do you ask your team to review the acceptance criteria in advance so they are aware of the challenges before the meeting?


    September 29, 2016 at 3:05 am
    • Divya Chopra

      I would start by asking why the developers why they feel a need for that level of detail during sprint planning.
      Preparation by attendees is key to the success of every meeting, and in the case of planning the best preparation would be to have a good idea of the acceptance criteria on the highest priority stories required to meet the sprint goal. In order for this to work, the product owner will need to provide the sprint goal by the last day of the previous sprint and have the backlog prioritised, so that the team can spend any time they have after the retrospective on preparation for sprint planning.
      Another common pattern is the focus on hours on tasks, which gets the team to feel the pressure to capture every task during sprint planning. This type of detail is not necessary during sprint planning, and the team should be comfortable with knowing 60-70% of task creation during sprint planning is sufficient, with room for smaller tasks to be added during the sprint. I mean, a tester won’t miss all the positive testing, but may miss a few negative or what if tests that wouldn’t take as long, and may not be as critical! Of course this also means that the focus on committed hours vs capacity needs to be done away with, by trusting the team to use their own time wisely and as effectively as possible.
      Hope this helps.

      October 5, 2016 at 10:28 am
    • Have you tried using a tool to streamline your meetings? This allows for everyone to input their comments, and have access to everyone’s comments at a time, instead of waiting for their turn.
      Tyr it at: PlanningWith.Cards
      Cool stuff.

      March 14, 2017 at 11:46 am
  • Prioritising the stories and making the tasks short are really good points as described in the post.
    We at Wizergos have developed this feature in our tool to keep the sprint planning meeting short, smooth and more effective.
    Following are some of the things we find it helpful in the product for our project execution.

    1. During planning while moving stories to the sprint from backlog so many back and forth happens like how much of the priority tasks get completed , is someone getting overloaded. During meeting, attendees can view a real time dashboard (shared across all attendees) of the backlogs , tasks under this sprint and how much is each person loaded, with which With edit access for all attendees, It becomes easier to plan and get a real sense of the sprint goal rather than emotionally going for more number of tasks.
    2. Another issue also is the execution of the plan. In daily stand up meetings, in the tool attendees also can update status of each tasks. After the meeting , the auto generated minutes are sent to each attendees with a summarised table of the status of sprint.

    You can go through the video ( for more information.

    March 22, 2017 at 7:09 pm
  • Nur Llobera

    Hi, very nice article!
    Do you estimate also the tasks into hours? Why do you add a meeting as a task?

    April 11, 2017 at 9:03 pm
      • Nur Llobera

        Thank you for your fast reply!
        I am new at this field and I am a bit focused. I read the book “Agile Estimating and Planning” from Mike Cohn and he says he estimates User Stories with ideal days or Story Points but each task from a User Story should be estimated by hours. That is confusing for me because it is the first time I read to do something like that.

        I also read very often, in some books and many blogs, that we shouldn’t split stories into tasks. It is also confusing, maybe I am misunderstanding the meaning of a task? For example, Mike Cohn in his book also says to not split stories into tasks, but when he does the Sprint Planning he decomposes the Stories exactly like you do (i.e., into tasks). What I am misunderstanding?

        April 12, 2017 at 7:36 pm
          • Nur Llobera

            Ah, now everything is much more clear for me. Thank you very much!

            April 13, 2017 at 7:44 pm
  • Pietro Maffi

    Hi, very nice article!

    April 19, 2017 at 6:59 pm
  • Lora Vardarova

    Added it to the Awesome List of resources on Agile Software Development:
    Add your favourites and/or let me know if there is a topic you would like this list to include.

    September 26, 2017 at 9:43 am

Post a Comment