How to account for Sprint Planning? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 4 years ago.

Improve this question

We are a small group of 3 developers working on a project, using Scrum.

We are using 6 hrs/day/developer for capacity planning. My question is - if we are using 2 week Sprints and spend most of the day (5-6 hours) doing Sprint Planning, should we consider this time as part of the iteration (i.e that is why we are using 6 hr/day to account for things like this).

To me, this falls outside capacity planning as the 6 hr/day/dev is only to account for productive time doing normal things that a developer does on a daily basis....

Answer 1

No, you should not consider the sprint planning as part of the sprint iteration.

The hours the team spends during sprint planning is not considered when calculating the development team's capacity, as the time spent in this meeting does not contribute to the development of stories.

Answer 2

You should do capacity planning in terms of stories. How many stories can you do this week? In this way you don't need to account for planning because it's not a story.

If your stories have sizes so different that you can't really plan sensibly without accounting for it:

• estimate the stories in arbitrary "points" (basically size them one against the other) (good)

or

• break your stories so they all become equally small (better)

In either case, you don't need to account for planning anywhere.

Answer 3

Sprint planning time should not be accounted in sprint iteration. But sprint planning should be completed in 2-3 hrs, not be done the whole day. Since you say your team is small consisting of 3 people, then ideally sprint planning should be completed within this time. So rest of the day is still available for sprint tasks.

Answer 4

I have tried a few different things, but here are the ideals that have worked best for me:

• Think of dev work as 'closed door' costs: how long would it take if she was never distracted by emails, meetings, phone calls, lunch, beer runs, etc.
• Identify, for your team, the ratio between 'closed door' costs and real life. Do your planning in 'closed door' (easier for devs to estimate) and use history to identify the ratio. This also allows you to try things out to lower the ratio (free soda/lunch delivery, email filters between 10am and 4pm, etc.)
• Consider sprints as having a full day for planning, stabilization, and review. So for a two week sprint, use Day 1 for planning, Day 9 for stabilization, and Day 10 for review/retrospective.

So if you have 5 developers working 8 hours a day for a two week sprint, and you figure out that your closed door/open door ratio is 1.5, you have 5.33 closed hours * 5 devs * 7 days = 186.6 hours of work you can plan for.

If you have a strong SCRUM master (or other process leader) and push your team to have a complete definition of 'Done' (i.e. documented, tested, buddy built, and integration tested), you won't need a stabilization day, but it takes some effort to get there.

The benefit of this blended process is that you can use the open/closed ratios to understand each developers work habits (some are great estimators and have a ratio of 1, some people are pessimistic about everything and might have a ratio under 1).