0

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....

Nat Naydenova
  • 771
  • 2
  • 12
  • 30
silverArc
  • 938
  • 1
  • 11
  • 19
  • 2
    I'm not sure it's exactly off-topic here, but it will likely play better in http://programmers.stackexchange.com/ as it's really more about process than programming. – Don Roby Oct 23 '13 at 01:22
  • 1
    I agree, not sure this fits here. That being said, at work we do include design/planning day in the 2-week sprint but do not include it when we set our personal capacity. So in a 2-week sprint the max number of days each member can commit to is 9, and then subtracting from there for meetings, out of work events, etc. However we also take it out of an 8-hour day. – Patrick Oct 23 '13 at 01:33
  • 4
    I'm voting to close this question as off-topic because [project management is now off-topic on Stack Overflow](//meta.stackoverflow.com/questions/343829/is-stack-overflow-an-appropriate-website-to-ask-about-project-management-issues/343841#343841). Ask these questions on [SoftwareEngineering.SE](//softwareengineering.stackexchange.com/) and [ProjectManagement.SE](//pm.stackexchange.com/) instead. (You can also flag for moderator intervention to have this question migrated.) – robinCTS Oct 28 '17 at 02:52

4 Answers4

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.

Sklivvz
  • 30,601
  • 24
  • 116
  • 172
1

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.

Sushma R
  • 70
  • 8
1

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).

JasonRShaver
  • 4,344
  • 3
  • 32
  • 39
0

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.

Ben Smith
  • 19,589
  • 6
  • 65
  • 93