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;
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
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
add a comment
|
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
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
add a comment
|
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
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
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
scrum sprint sprint-planning timeboxing
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
edited Sep 19 at 13:04
Sarov
10.6k4 gold badges22 silver badges44 bronze badges
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
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
asked Sep 18 at 6:11
Mingyue XieMingyue Xie
1531 silver badge7 bronze badges
1531 silver badge7 bronze badges
add a comment
|
add a comment
|
6 Answers
6
active
oldest
votes
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.
answered Sep 18 at 12:32
Thomas OwensThomas Owens
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
add a comment
|
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.
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
add a comment
|
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.
- https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings
answered Sep 19 at 17:38
bobbob
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
add a comment
|
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.
answered Sep 19 at 19:11
hobbshobbs
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
add a comment
|
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.
answered Sep 18 at 23:20
Justin GrantJustin Grant
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
add a comment
|
I would say the length of a sprint planning session depends on a number of things:
- Has the backlog been groomed/refined?
- Do you have a Definition of Ready that stories/features must adhere to?
- Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
- How long is the sprint?
- What's your capacity? Is it based off your velocity?
- How good is your product owner?
- How testable are the stories?
- 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.
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
add a comment
|
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
answered Sep 18 at 12:32
Thomas OwensThomas Owens
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
add a comment
|
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.
answered Sep 18 at 12:32
Thomas OwensThomas Owens
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
add a comment
|
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.
answered Sep 18 at 12:32
Thomas OwensThomas Owens
7,44417 silver badges35 bronze badges
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.
answered Sep 18 at 12:32
Thomas OwensThomas Owens
7,44417 silver badges35 bronze badges
edited Sep 18 at 14:13
answered Sep 18 at 12:32
Thomas OwensThomas Owens
7,44417 silver badges35 bronze badges
answered Sep 18 at 12:32
Thomas OwensThomas Owens
7,44417 silver badges35 bronze badges
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
add a comment
|
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
add a comment
|
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.
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
add a comment
|
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.
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
add a comment
|
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.
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
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.
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
edited Sep 18 at 6:42
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
answered Sep 18 at 6:31
BogdanBogdan
9906 bronze badges
9906 bronze badges
add a comment
|
add a comment
|
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.
- https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings
answered Sep 19 at 17:38
bobbob
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
add a comment
|
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.
- https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings
answered Sep 19 at 17:38
bobbob
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
add a comment
|
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.
- https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings
answered Sep 19 at 17:38
bobbob
1513 bronze badges
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.
- https://www.fastcompany.com/3033232/9-science-backed-methods-for-more-productive-meetings
answered Sep 19 at 17:38
bobbob
1513 bronze badges
edited Sep 19 at 17:44
answered Sep 19 at 17:38
bobbob
1513 bronze badges
answered Sep 19 at 17:38
bobbob
1513 bronze badges
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
add a comment
|
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
add a comment
|
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.
answered Sep 19 at 19:11
hobbshobbs
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
add a comment
|
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.
answered Sep 19 at 19:11
hobbshobbs
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
add a comment
|
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.
answered Sep 19 at 19:11
hobbshobbs
1412 bronze badges
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.
answered Sep 19 at 19:11
hobbshobbs
1412 bronze badges
answered Sep 19 at 19:11
hobbshobbs
1412 bronze badges
answered Sep 19 at 19:11
hobbshobbs
1412 bronze badges
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
add a comment
|
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
add a comment
|
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.
answered Sep 18 at 23:20
Justin GrantJustin Grant
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
add a comment
|
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.
answered Sep 18 at 23:20
Justin GrantJustin Grant
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
add a comment
|
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.
answered Sep 18 at 23:20
Justin GrantJustin Grant
1313 bronze badges
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.
answered Sep 18 at 23:20
Justin GrantJustin Grant
1313 bronze badges
edited Sep 27 at 0:32
answered Sep 18 at 23:20
Justin GrantJustin Grant
1313 bronze badges
answered Sep 18 at 23:20
Justin GrantJustin Grant
1313 bronze badges
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
add a comment
|
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
add a comment
|
I would say the length of a sprint planning session depends on a number of things:
- Has the backlog been groomed/refined?
- Do you have a Definition of Ready that stories/features must adhere to?
- Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
- How long is the sprint?
- What's your capacity? Is it based off your velocity?
- How good is your product owner?
- How testable are the stories?
- 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.
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
add a comment
|
I would say the length of a sprint planning session depends on a number of things:
- Has the backlog been groomed/refined?
- Do you have a Definition of Ready that stories/features must adhere to?
- Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
- How long is the sprint?
- What's your capacity? Is it based off your velocity?
- How good is your product owner?
- How testable are the stories?
- 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.
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
add a comment
|
I would say the length of a sprint planning session depends on a number of things:
- Has the backlog been groomed/refined?
- Do you have a Definition of Ready that stories/features must adhere to?
- Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
- How long is the sprint?
- What's your capacity? Is it based off your velocity?
- How good is your product owner?
- How testable are the stories?
- 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.
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
I would say the length of a sprint planning session depends on a number of things:
- Has the backlog been groomed/refined?
- Do you have a Definition of Ready that stories/features must adhere to?
- Are you sizing tickets using planning poker cards? Or just t-shirt sizes?
- How long is the sprint?
- What's your capacity? Is it based off your velocity?
- How good is your product owner?
- How testable are the stories?
- 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.
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
answered Sep 20 at 13:48
spikey_richiespikey_richie
1033 bronze badges
1033 bronze badges
add a comment
|
add a comment
|
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
