How to do resource capacity planning without detail stories w/ advanced roadmaps at the early stage

[natalieh]

Generally in the early year, team want to know their resource capacity vs their year end roadmap so as to do their annual capacity planning, at such stage, team will only have the hight level requirement for epic/feature, without detail stories created, in such case, how can we use Advanced Roadmap to do the capacity planning?

[Rick Olson]

We accomplish this by breaking down each project into a collection of epics, one epic per team. Then, each team provides an Original Estimate for their piece of the project using their epic to record that. Finally, with the team capacity in Advanced Roadmaps, we import the epics for all projects so that we can let Advanced Roadmaps suggest the appropriate number of sprints for the team.

[Shirley]

@Rick Olson, does that mean your teams use the same estimation method for these epics as for detail stories, such as story points or hours? In your situation, does the suggested number of sprints account for multiple concurrent epics or one at a time? Can you provide an example?

I'm new to Advanced Roadmaps and trying to visualize how that would work when, say, Epic 1 for Widget A is roughly estimated at about an average of 10 story points of work per sprint and the start and end dates cover a period of six sprints. Let's also say this team's capacity is about 30 story points per sprint. Would the estimate on that epic be 60 story points and Advanced Roadmaps would average it out over six sprints because of the dates or refer to team capacity of 30 story points and suggest two sprints?

[Rick Olson]

Yes, we use hours for our estimates. By having the epic assigned to the team, the Original Estimate represents all of the work. However, Advanced Roadmaps uses the Remaining effort to forecast with. By example, if I have Team A, and they picked a t-shirt size the amounts to 500 hours, and their team velocity was 100 hours, Advanced roadmaps will show the duration of that epic across 5 sprints.

Looking at your example, while we don't use points, my belief is that algorithms result in the same outcome.  Then lets say that the Epic for Widget A is 60 points (10 points per sprint; six sprints). Getting AR to spread that across multiple sprints isn't something that we look to do since we are constantly release updates ASAP. For us, that 60 point epic would show a duration of 2 sprints.

[natalieh]

Hi @Rick Olson  Thanks for your suggestion. I do have another question, I actually did the same way as you do (I use estimation(hours/days) vs start/due date vs team sprint capacity. But I do want to know whether team's capacity in specific sprint is overloaded or not. 

If we break down epic to stories with story points or hours/days, the sprint bar will turn red and remind us the sprint is overloaded. 

But with the approach you are using now, the sprint bar doesn't do any overloaded call out. 

How do you resolve this issue?

[Rick Olson]

At this high level of planning, we don't have stories but only epics with hours for their team's work. We have a large number of initiatives (i.e. projects) and each initiative has it's collection of epics.

Because we are doing high-level planning, we haven't decomposed the epics into stories. That means that we don't plan with actual sprints so we never get that red overallocated red bar.

We leverage ARs ability to create projected sprints and I use the Auto-schedule feature to have AR propose a nice full-loaded projected set of sprints for each of the 22 scrum teams. If we find that the due date for an initiative cannot be met with the existing capacity of one or more teams, if we cannot reprioritize the initiatives I increase the capacity of those teams where the projected due date exceeds or promised delivery data. I then rerun the Auto-schedule feature until we do hit our due dates. The result is that I know how many people each scrum team needs to have, which leads a discussion with management about moving people from one team to another, or to go pick up some contractors to fill the projected shortage.

And, one more thing: I don't save all of these changes to Jira since its a capacity modeling exercise. If I were to save them to Jira, every issue would be loaded with new target start and target end dates which would immediately drive our 'projected past due delivery report' nuts for those teams that need more capacity.