Is it really necessary to have a four hour meeting in Sprint planning?When should you do sprint planning?Participants of sprint planning meeting - Is it essential to involve part-time team membersWhen is the best time to create story tasks?Is it okay to have a sprint where the team commits to zero story points?How can we fix Sprint Planning meetings that are unproductive?What should we do if there are not enough PBIs to fill a final Sprint in Scrum?What Scrum especify when the time of the sprint planning is exhausted before you finish with all task?Are all the scrum ceremonies included in the sprint timebox in Scrum?Sprints Starting Mid-Week in ScrumSprint planning

Why are file URLs marked as not secure while HTTPS URLs are marked as secure in browsers?

60's or earlier fantasy about two children pranksters who turn out to be persian deities

Suppose I capture encrypted data that I want to decrypt. Could I use a server farm to decrypt?

Employer wants me to do something explicitly illegal

How to retain new users on a Q&A site effectively?

How often are there lunar eclipses on Jupiter

Cheap and safe way to dim 100+ 60W Incandescent bulbs

Starting with D&D: Starter Set vs Dungeon Master's Guide

What are the units of the product of two signals?

Why is the tangent of an angle called that?

Journal editor made bad edits to my (accepted) paper - how do I respond?

Pointlessly recurse down the alphabet

How to obtain sodium oxide from sodium chloride?

What is a recently obsolete computer storage device that would be significantly difficult to extract data from?

Someone said to me, "We basically literally did." What were they trying to express to me?

Because things smell, is everything evaporating?

What does "können" refer to in this sentence?

Convention for inverted signal

What is the difference between "cat < filename" and "cat filename"?

What's a good use case for SELECT * in production code?

If password expiration is applied, should door-lock expiration be applied too?

I peer reviewed a paper and found it to be sound - technically and language-wise. How should I write the review report?

A movie about kids having imaginary friends

How to deal with an employee who is requesting a demotion?



Is it really necessary to have a four hour meeting in Sprint planning?


When should you do sprint planning?Participants of sprint planning meeting - Is it essential to involve part-time team membersWhen is the best time to create story tasks?Is it okay to have a sprint where the team commits to zero story points?How can we fix Sprint Planning meetings that are unproductive?What should we do if there are not enough PBIs to fill a final Sprint in Scrum?What Scrum especify when the time of the sprint planning is exhausted before you finish with all task?Are all the scrum ceremonies included in the sprint timebox in Scrum?Sprints Starting Mid-Week in ScrumSprint planning






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;

.everyonelovesstackoverflowposition:absolute;height:1px;width:1px;opacity:0;top:0;left:0;pointer-events:none;








15


















According to Wikipedia, it is recommended that there should be a four hour meeting in a
two-week sprint planning (pro-rata for other sprint durations).



Is it necessary? Why?










share|improve this question

































    15


















    According to Wikipedia, it is recommended that there should be a four hour meeting in a
    two-week sprint planning (pro-rata for other sprint durations).



    Is it necessary? Why?










    share|improve this question





























      15













      15









      15








      According to Wikipedia, it is recommended that there should be a four hour meeting in a
      two-week sprint planning (pro-rata for other sprint durations).



      Is it necessary? Why?










      share|improve this question
















      According to Wikipedia, it is recommended that there should be a four hour meeting in a
      two-week sprint planning (pro-rata for other sprint durations).



      Is it necessary? Why?







      scrum sprint sprint-planning timeboxing






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Sep 19 at 13:04









      Sarov

      10.6k4 gold badges22 silver badges44 bronze badges




      10.6k4 gold badges22 silver badges44 bronze badges










      asked Sep 18 at 6:11









      Mingyue XieMingyue Xie

      1531 silver badge7 bronze badges




      1531 silver badge7 bronze badges























          6 Answers
          6






          active

          oldest

          votes


















          27



















          I'm going to slightly disagree with Bogdan's answer.



          The Scrum Guide does say that:




          Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




          We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.



          Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.



          I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.






          share|improve this answer























          • 11





            +1 for stating that a meeting can end before its timebox elapses.

            – Bart van Ingen Schenau
            Sep 18 at 12:59






          • 4





            The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

            – corsiKa
            Sep 19 at 6:38






          • 3





            It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

            – barrick
            Sep 19 at 7:53






          • 1





            Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

            – bob
            Sep 19 at 17:32












          • @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

            – Monty Harder
            Sep 19 at 21:05


















          9



















          The Scrum Guide mentions that:




          Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




          If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.



          Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.



          The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.






          share|improve this answer



































            5



















            A four hour long meeting is harmful



            Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:




            What’s your record for longest meeting?



            Can anyone beat my four-hour marathon? (I bet many of you can!)



            When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:




            Work expands to the time you schedule for it.




            For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.



            Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.



            For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.



            The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.




            It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).



            For the love of humanity please keep meetings short!



            Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.



            1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings





            share|improve this answer




























            • How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

              – Sarov
              Sep 19 at 17:59






            • 2





              basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

              – Ewan
              Sep 19 at 18:45


















            4



















            In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.






            share|improve this answer


























            • You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

              – jitendragarg
              Sep 27 at 8:52


















            3



















            For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.



            That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:



            • Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.

            • Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.

            • We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.

            • About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.

            • Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".

            • For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.

            • Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

            Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.



            True, there was other planning work happening outside Sprint Planning.
            But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.






            share|improve this answer




























            • Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

              – jitendragarg
              Sep 27 at 8:54











            • Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

              – Justin Grant
              Sep 30 at 22:22


















            0



















            I would say the length of a sprint planning session depends on a number of things:



            1. Has the backlog been groomed/refined?

            2. Do you have a Definition of Ready that stories/features must adhere to?

            3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?

            4. How long is the sprint?

            5. What's your capacity? Is it based off your velocity?

            6. How good is your product owner?

            7. How testable are the stories?

            8. Do you have a sprint goal?

            1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.



            2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...



            3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.



            4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.



            5 - Are you dev heavy? Test heavy?



            6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?



            7 - Stories which are hard to automate may require further discussion.



            8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.






            share|improve this answer



























              Your Answer








              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "208"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              noCode: true, onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );














              draft saved

              draft discarded
















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f27208%2fis-it-really-necessary-to-have-a-four-hour-meeting-in-sprint-planning%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown


























              6 Answers
              6






              active

              oldest

              votes








              6 Answers
              6






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              27



















              I'm going to slightly disagree with Bogdan's answer.



              The Scrum Guide does say that:




              Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




              We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.



              Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.



              I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.






              share|improve this answer























              • 11





                +1 for stating that a meeting can end before its timebox elapses.

                – Bart van Ingen Schenau
                Sep 18 at 12:59






              • 4





                The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

                – corsiKa
                Sep 19 at 6:38






              • 3





                It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

                – barrick
                Sep 19 at 7:53






              • 1





                Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

                – bob
                Sep 19 at 17:32












              • @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

                – Monty Harder
                Sep 19 at 21:05















              27



















              I'm going to slightly disagree with Bogdan's answer.



              The Scrum Guide does say that:




              Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




              We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.



              Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.



              I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.






              share|improve this answer























              • 11





                +1 for stating that a meeting can end before its timebox elapses.

                – Bart van Ingen Schenau
                Sep 18 at 12:59






              • 4





                The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

                – corsiKa
                Sep 19 at 6:38






              • 3





                It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

                – barrick
                Sep 19 at 7:53






              • 1





                Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

                – bob
                Sep 19 at 17:32












              • @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

                – Monty Harder
                Sep 19 at 21:05













              27















              27











              27









              I'm going to slightly disagree with Bogdan's answer.



              The Scrum Guide does say that:




              Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




              We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.



              Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.



              I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.






              share|improve this answer
















              I'm going to slightly disagree with Bogdan's answer.



              The Scrum Guide does say that:




              Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




              We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is shorter than 4 weeks, "the event is usually shorter". The Scrum Guide does not give a suggestion on how to scale the timebox for an event for shorter Sprints, nor does it even say that the timebox needs to be scaled for shorter Sprints.



              Common advice is to scale linearly. That is, if a Sprint with a timebox of 4 weeks has a timebox of 8 hours for Sprint Planning, a Sprint of 2 weeks would have a timebox of 4 hours for Sprint Planning. In my experiences, this works out well for scheduling purposes. It is important to keep in mind that a timebox is a constraint, not a mandatory duration - the event ends when its intention has been fulfilled and the maximum time should be the timebox.



              I've found that if you spend sufficient time on Product Backlog refinement activities before Sprint Planning, then Sprint Planning will be much more efficient. The Scrum Guide recommends that approximately 10% of the Development Team's capacity be allocated to refinement, but note that this isn't a timebox - it may be more, it may be less, but it's a good guideline to keep in mind. If you go into Sprint Planning and the bulk of the work at the top of the Product Backlog is well refined and understood by the Development Team, identifying which Product Backlog Items can be done within the Sprint becomes much easier and the team can focus on developing a plan for getting that subset of items to Done.







              share|improve this answer















              share|improve this answer




              share|improve this answer








              edited Sep 18 at 14:13

























              answered Sep 18 at 12:32









              Thomas OwensThomas Owens

              7,44417 silver badges35 bronze badges




              7,44417 silver badges35 bronze badges










              • 11





                +1 for stating that a meeting can end before its timebox elapses.

                – Bart van Ingen Schenau
                Sep 18 at 12:59






              • 4





                The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

                – corsiKa
                Sep 19 at 6:38






              • 3





                It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

                – barrick
                Sep 19 at 7:53






              • 1





                Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

                – bob
                Sep 19 at 17:32












              • @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

                – Monty Harder
                Sep 19 at 21:05












              • 11





                +1 for stating that a meeting can end before its timebox elapses.

                – Bart van Ingen Schenau
                Sep 18 at 12:59






              • 4





                The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

                – corsiKa
                Sep 19 at 6:38






              • 3





                It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

                – barrick
                Sep 19 at 7:53






              • 1





                Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

                – bob
                Sep 19 at 17:32












              • @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

                – Monty Harder
                Sep 19 at 21:05







              11




              11





              +1 for stating that a meeting can end before its timebox elapses.

              – Bart van Ingen Schenau
              Sep 18 at 12:59





              +1 for stating that a meeting can end before its timebox elapses.

              – Bart van Ingen Schenau
              Sep 18 at 12:59




              4




              4





              The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

              – corsiKa
              Sep 19 at 6:38





              The vast majority of people I know see a meeting ending early as a Very Good Thing. Often they'll things like "Wow, 30 minutes everyone will think I'm in a meeting so I can get some uninterrupted work done." They say it like a joke, but in the words of Dane Cook, it's funny because it's true.

              – corsiKa
              Sep 19 at 6:38




              3




              3





              It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

              – barrick
              Sep 19 at 7:53





              It doesn't have to be an unbroken four hours either. Allow a decent chunk of time, half an hour or so, at an appropriate point for people to break and let their brains rest and refocus

              – barrick
              Sep 19 at 7:53




              1




              1





              Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

              – bob
              Sep 19 at 17:32






              Yeah a 4 hour meeting is 3 hours too long in my opinion. By the end of it my brain is going to be ready to explode. So I'm all for shortening it, or if you absolutely can't do that, then at least split it into chunks of no more than 1 hour each. But please lets work to end multi-hour meetings, for the good of humanity! :)

              – bob
              Sep 19 at 17:32














              @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

              – Monty Harder
              Sep 19 at 21:05





              @corsiKa Long ago I saw a time-management film that made the suggestion that people book a 1-hour "meeting" every morning and every afternoon. The idea was that you could get more work done in those 2h than the other 6 combined. Nothing since has led me to question the veracity of that idea.

              – Monty Harder
              Sep 19 at 21:05













              9



















              The Scrum Guide mentions that:




              Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




              If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.



              Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.



              The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.






              share|improve this answer
































                9



















                The Scrum Guide mentions that:




                Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




                If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.



                Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.



                The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.






                share|improve this answer






























                  9















                  9











                  9









                  The Scrum Guide mentions that:




                  Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




                  If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.



                  Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.



                  The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.






                  share|improve this answer
















                  The Scrum Guide mentions that:




                  Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.




                  If you keep the same train of thought, that translates to a maximum of four hours for a two week sprint.



                  Events are time boxed in Scrum so that people stay focused on the activity. Imagine if the Daily Standup wasn't time boxed, people will just talk and talk and talk. Same with the Sprint Planning, people need to stay focused to plan the Sprint. If you spend a lot of time planning and go beyond the four hours then that's a sign of possible issues (maybe someone hijacks the meeting, maybe stories aren't properly refined, maybe people are day dreaming, etc) so in normal conditions the Sprint Plannings will take less than four hours.



                  The four hour per two week Sprint is a maximum. It does not mandate that you spend exactly that much amount of time on the activity. If you plan properly and you finish your planning sooner, then that's no problem at all.







                  share|improve this answer















                  share|improve this answer




                  share|improve this answer








                  edited Sep 18 at 6:42

























                  answered Sep 18 at 6:31









                  BogdanBogdan

                  9906 bronze badges




                  9906 bronze badges
























                      5



















                      A four hour long meeting is harmful



                      Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:




                      What’s your record for longest meeting?



                      Can anyone beat my four-hour marathon? (I bet many of you can!)



                      When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:




                      Work expands to the time you schedule for it.




                      For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.



                      Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.



                      For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.



                      The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.




                      It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).



                      For the love of humanity please keep meetings short!



                      Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.



                      1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings





                      share|improve this answer




























                      • How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                        – Sarov
                        Sep 19 at 17:59






                      • 2





                        basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                        – Ewan
                        Sep 19 at 18:45















                      5



















                      A four hour long meeting is harmful



                      Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:




                      What’s your record for longest meeting?



                      Can anyone beat my four-hour marathon? (I bet many of you can!)



                      When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:




                      Work expands to the time you schedule for it.




                      For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.



                      Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.



                      For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.



                      The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.




                      It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).



                      For the love of humanity please keep meetings short!



                      Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.



                      1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings





                      share|improve this answer




























                      • How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                        – Sarov
                        Sep 19 at 17:59






                      • 2





                        basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                        – Ewan
                        Sep 19 at 18:45













                      5















                      5











                      5









                      A four hour long meeting is harmful



                      Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:




                      What’s your record for longest meeting?



                      Can anyone beat my four-hour marathon? (I bet many of you can!)



                      When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:




                      Work expands to the time you schedule for it.




                      For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.



                      Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.



                      For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.



                      The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.




                      It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).



                      For the love of humanity please keep meetings short!



                      Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.



                      1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings





                      share|improve this answer
















                      A four hour long meeting is harmful



                      Four hours is way too long for a productive meeting [1]. Here's an excerpt from an article by FastCompany:




                      What’s your record for longest meeting?



                      Can anyone beat my four-hour marathon? (I bet many of you can!)



                      When it comes to meeting pain points, length often tops the list. How is it that meetings tend to go on so long, sometimes (OK, many times) unnecessarily? Here’s an old project management adage that might explain it:




                      Work expands to the time you schedule for it.




                      For this reason, you may want to keep meetings to 15 minutes or shorter, whenever possible. Yahoo’s Marissa Mayer will schedule 10-minute meetings, out of necessity for her busy schedule. The team at Percolate sets 15 minutes as the default length for all meetings, adjusting up or down as needed. Percolate values the 15-minute default so highly, they framed it in their set of six meeting rules.



                      Why might it seem like 15 minutes is an ideal starting point for meeting length? For one, it’s easy to schedule in an Outlook calendar or Google calendar. Though the default in most calendar apps is 30 minutes, you can quite easily adjust down to 15-minute increments as that’s how most schedule grids are created.



                      For the science behind the 15-minute rule, you need look no further than a TED talk. Each TED talk is kept to 18 minutes or shorter, the same time as a coffee break and a helpful constraint for presenters to organize their thoughts. Scientifically, 18 minutes fits right in with the research on attention spans: 10 to 18 minutes is how long most people can pay attention before checking out.



                      The 18-minute max has physiological roots. Our bodies require a large amount of glucose, oxygen, and blood flow when the brain processes new information. Sooner or later, we feel physically fatigued.




                      It's true that some people (managers usually) like long meetings, but for many people long meetings 1) kill productivity by causing significant mental fatigue, 2) harm morale because they're seen as almost a form of torture, and 3) signal incompetence (I tend not to think my team knows where its going if they have to have 2+ hour meetings all the time to figure things out).



                      For the love of humanity please keep meetings short!



                      Seriously, unless you want your team to start hating you, keep meetings to a minimum and make them highly focused. It takes more work but it will 1) keep your team from getting as drained mentally; 2) keep your team happier; and 3) make your team think more highly of your organizational skills. I would seriously consider leaving any team that had regular mandatory four hour meetings, and I'm sure I'm not alone.



                      1. https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings






                      share|improve this answer















                      share|improve this answer




                      share|improve this answer








                      edited Sep 19 at 17:44

























                      answered Sep 19 at 17:38









                      bobbob

                      1513 bronze badges




                      1513 bronze badges















                      • How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                        – Sarov
                        Sep 19 at 17:59






                      • 2





                        basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                        – Ewan
                        Sep 19 at 18:45

















                      • How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                        – Sarov
                        Sep 19 at 17:59






                      • 2





                        basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                        – Ewan
                        Sep 19 at 18:45
















                      How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                      – Sarov
                      Sep 19 at 17:59





                      How exactly would you suggest doing a Sprint Planning for two weeks (that is: planning, estimating, discussing and reprioritizing the work for 400-720 man-hours) in 18 minutes? That sounds like a fairy-tale to me.

                      – Sarov
                      Sep 19 at 17:59




                      2




                      2





                      basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                      – Ewan
                      Sep 19 at 18:45





                      basically you spread out the planning into hundreds of small decisions. are we making an app or a website? what tech stack? what front end framework? list the pages, get the designers to make a design for each page. Once you have the framework decided the sprint planning comes down to "any questions about the next ten stories?"

                      – Ewan
                      Sep 19 at 18:45











                      4



















                      In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.






                      share|improve this answer


























                      • You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                        – jitendragarg
                        Sep 27 at 8:52















                      4



















                      In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.






                      share|improve this answer


























                      • You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                        – jitendragarg
                        Sep 27 at 8:52













                      4















                      4











                      4









                      In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.






                      share|improve this answer














                      In my opinion, no. I once took over leadership of a team that had 4-hour biweekly planning meetings, and it was miserable. No one is effective towards the end of a 4-hour meeting, and it led to plenty of bad decisions. I was eventually able to bring it down to an average of 90 minutes (in a 2-hour slot) and the resulting work was greatly improved. The key, of course, is preparation — and, if necessary, cutting off discussion within the meeting. The backlog should be in a good state before you come into planning. If a story isn't well-defined by backlog grooming the week before, then you aren't ready to take it on. If you know what you're doing but estimation becomes a discussion about how to do it, then you need to do a confidence check. Either you decide as a team that you're discussing details which can be figured out after planning without major impact on the timeline, or you decide that there's major uncertainty in the approach, and kick the story out in favor of a research spike which will let you do it with confidence. Either way, doing the research during the planning is the worst available option.







                      share|improve this answer













                      share|improve this answer




                      share|improve this answer










                      answered Sep 19 at 19:11









                      hobbshobbs

                      1412 bronze badges




                      1412 bronze badges















                      • You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                        – jitendragarg
                        Sep 27 at 8:52

















                      • You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                        – jitendragarg
                        Sep 27 at 8:52
















                      You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                      – jitendragarg
                      Sep 27 at 8:52





                      You don't have to plan 4 hours together. It can be 1hour session with a break for 15 minutes, then another session. Also, timebox is max limit. There is no minimum limit. As team gains more understanding of the product they are building, meeting time will automatically come down.

                      – jitendragarg
                      Sep 27 at 8:52











                      3



















                      For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.



                      That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:



                      • Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.

                      • Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.

                      • We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.

                      • About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.

                      • Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".

                      • For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.

                      • Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

                      Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.



                      True, there was other planning work happening outside Sprint Planning.
                      But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.






                      share|improve this answer




























                      • Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                        – jitendragarg
                        Sep 27 at 8:54











                      • Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                        – Justin Grant
                        Sep 30 at 22:22















                      3



















                      For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.



                      That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:



                      • Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.

                      • Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.

                      • We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.

                      • About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.

                      • Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".

                      • For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.

                      • Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

                      Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.



                      True, there was other planning work happening outside Sprint Planning.
                      But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.






                      share|improve this answer




























                      • Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                        – jitendragarg
                        Sep 27 at 8:54











                      • Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                        – Justin Grant
                        Sep 30 at 22:22













                      3















                      3











                      3









                      For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.



                      That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:



                      • Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.

                      • Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.

                      • We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.

                      • About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.

                      • Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".

                      • For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.

                      • Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

                      Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.



                      True, there was other planning work happening outside Sprint Planning.
                      But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.






                      share|improve this answer
















                      For a team that's done minimal pre-meeting preparation, is working on a new project, and/or who are new to working together, 4 hours for a 2-week sprint seems reasonable. It's better to waste a few minutes in a meeting than waste a few days of a developer's time during the sprint because a task wasn't clear enough or if technical blockers weren't discussed during sprint planning.



                      That said, it's definitely possible to reduce the time required for Sprint Planning meetings without adding risk. Here's a few basic techniques that we used to reduce our average Sprint Planning meeting to less than 30 minutes per 3-week sprint for a 15-person team:



                      • Ensure that the backlog, and the top tasks therein, were ready at least several days ahead of the Sprint Planning meeting. Then require that everyone read all tasks before showing up at Sprint Planning meetings.

                      • Have one senior developer "pre-review" proposed sprint tasks to find technical blockers, unclear requirements, and other problems. Instead of wasting everyone's time if blockers were found during the Sprint Planning meeting, this technique limited the "find and fix blockers" impact to one developer plus the task owner. This role (the team called it "crap-master") rotated between a different senior developer in each sprint. That way one person didn't always end up with extra work.

                      • We did task estimation before Sprint Planning, at a weekly "estimation meeting". These were generally less than an hour unless there were lots of intra-dev-team arguments. If a task didn't fit in the hour, its estimation would get delayed until the following week, which was OK because there were three of these meetings per sprint. Doing estimation ahead of time made estimates more accurate, and it also made Sprint Planning easier and faster because devs were already familiar with each task.

                      • About 2 weeks before each sprint started, the dev manager would calculate sprint capacity (in points), taking into account holidays, vacations, etc. This, combined with the advance estimation meetings above, meant that PMs could figure out ahead of time which tasks would fit into the sprint so we don't waste time at Sprint Planning on tasks that won't fit in a sprint.

                      • Product Managers would groom the backlog ahead of time. 3 days before Sprint Planning, they would send a "Draft Sprint Plan" email to the team which listed the (usually already estimated-- see above) tasks at the top of the backlog and briefly summarized (usually in one sentence) each sprint task including why (business purpose) of the task. This mail also was a good place to explain overall goals and risks for the sprint, e.g. "This is the last sprint before releasing our dark-mode feature" or "Scott will be on vacation next week, so ask any questions before he leaves".

                      • For tasks that were too large or unknown to estimate, instead of wasting everyone's time arguing about their scope, PMs would simply assign a specific number of points (aka "timebox") to that task. If the task couldn't fit into the timebox, devs would stop work and continue in a later sprint.

                      • Instead of spending everyone's time in Sprint Planning discussing code refactoring, upgrading build tools, and other "Technical Debt" tasks, the dev team had a fixed percentage of sprint capacity (e.g. 30%) that they could allocate to whatever technical-debt work they wanted. This let devs allocate these work without wasting the entire team's time in Sprint Planning.

                      Doing all the above wasn't easy. It required a lot of discipline from everyone on the team to each do their part. But all the prep work above made Sprint Planning meetings quick. PMs would go through the Sprint Draft email they sent several days earlier, devs would ask questions about specific tasks, and we'd wrap up. After a while of doing this, we could usually finish Sprint Planning in 20 minutes.



                      True, there was other planning work happening outside Sprint Planning.
                      But crucially that other planning work didn't require big blocks of time from the entire cross-functional team. So the overall efficiency of the team was improved. More importantly (for both the business and for team morale), sprints became more predictable with fewer all-nighters, fewer missed deadlines, and fewer arguments.







                      share|improve this answer















                      share|improve this answer




                      share|improve this answer








                      edited Sep 27 at 0:32

























                      answered Sep 18 at 23:20









                      Justin GrantJustin Grant

                      1313 bronze badges




                      1313 bronze badges















                      • Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                        – jitendragarg
                        Sep 27 at 8:54











                      • Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                        – Justin Grant
                        Sep 30 at 22:22

















                      • Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                        – jitendragarg
                        Sep 27 at 8:54











                      • Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                        – Justin Grant
                        Sep 30 at 22:22
















                      Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                      – jitendragarg
                      Sep 27 at 8:54





                      Estimation planning meeting is technically sprint planning. So, you just divided one session into multiple. It was not as much reduction in time required.

                      – jitendragarg
                      Sep 27 at 8:54













                      Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                      – Justin Grant
                      Sep 30 at 22:22





                      Hi @jitendragarg - Planning time is two-dimensional: number of hours times number of people. Our process changes noted above were mainly focused on reducing the "number of people" axis. We replaced a multi-hour whole-team sprint planning meeting with more focused, shorter meetings with fewer people. We also required more individual prep from PMs and a single rotating "crapmaster" senior developer. The net result was a huge (>50%) reduction in total team hours spent on planning, but without losing the benefits of having all developers and PMs understanding each task.

                      – Justin Grant
                      Sep 30 at 22:22











                      0



















                      I would say the length of a sprint planning session depends on a number of things:



                      1. Has the backlog been groomed/refined?

                      2. Do you have a Definition of Ready that stories/features must adhere to?

                      3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?

                      4. How long is the sprint?

                      5. What's your capacity? Is it based off your velocity?

                      6. How good is your product owner?

                      7. How testable are the stories?

                      8. Do you have a sprint goal?

                      1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.



                      2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...



                      3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.



                      4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.



                      5 - Are you dev heavy? Test heavy?



                      6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?



                      7 - Stories which are hard to automate may require further discussion.



                      8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.






                      share|improve this answer






























                        0



















                        I would say the length of a sprint planning session depends on a number of things:



                        1. Has the backlog been groomed/refined?

                        2. Do you have a Definition of Ready that stories/features must adhere to?

                        3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?

                        4. How long is the sprint?

                        5. What's your capacity? Is it based off your velocity?

                        6. How good is your product owner?

                        7. How testable are the stories?

                        8. Do you have a sprint goal?

                        1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.



                        2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...



                        3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.



                        4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.



                        5 - Are you dev heavy? Test heavy?



                        6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?



                        7 - Stories which are hard to automate may require further discussion.



                        8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.






                        share|improve this answer




























                          0















                          0











                          0









                          I would say the length of a sprint planning session depends on a number of things:



                          1. Has the backlog been groomed/refined?

                          2. Do you have a Definition of Ready that stories/features must adhere to?

                          3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?

                          4. How long is the sprint?

                          5. What's your capacity? Is it based off your velocity?

                          6. How good is your product owner?

                          7. How testable are the stories?

                          8. Do you have a sprint goal?

                          1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.



                          2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...



                          3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.



                          4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.



                          5 - Are you dev heavy? Test heavy?



                          6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?



                          7 - Stories which are hard to automate may require further discussion.



                          8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.






                          share|improve this answer














                          I would say the length of a sprint planning session depends on a number of things:



                          1. Has the backlog been groomed/refined?

                          2. Do you have a Definition of Ready that stories/features must adhere to?

                          3. Are you sizing tickets using planning poker cards? Or just t-shirt sizes?

                          4. How long is the sprint?

                          5. What's your capacity? Is it based off your velocity?

                          6. How good is your product owner?

                          7. How testable are the stories?

                          8. Do you have a sprint goal?

                          1 - If the backlog is in a bad shape, planning will take longer as you'll need to tease out the detail.



                          2 - If you have strict conditions, there may be some tickets up for discussion with respect to their scope, conditions of acceptance etc...



                          3 - Planning poker can take longer, as there is more discussion when someone pulls a 5 vs a 20.



                          4 - Sprint planning is usually 2 hours per week of development, but varies depending on who you ask.



                          5 - Are you dev heavy? Test heavy?



                          6 - Are they good at writing stories and conditions of acceptance? Are they aware of stakeholder priorities?



                          7 - Stories which are hard to automate may require further discussion.



                          8 - Won't really affect the length of sprint planning, but thought I'd add it in anyway.







                          share|improve this answer













                          share|improve this answer




                          share|improve this answer










                          answered Sep 20 at 13:48









                          spikey_richiespikey_richie

                          1033 bronze badges




                          1033 bronze badges































                              draft saved

                              draft discarded















































                              Thanks for contributing an answer to Project Management Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid


                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.

                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function ()
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f27208%2fis-it-really-necessary-to-have-a-four-hour-meeting-in-sprint-planning%23new-answer', 'question_page');

                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown









                              Popular posts from this blog

                              Tamil (spriik) Luke uk diar | Nawigatjuun

                              Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

                              Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?