Resource Planning

One of the most common questions I’m asked about running Agile projects and teams is how do I do resource planning. The short answer is that it’s a three or four step process; understand available time, iteration planning, release planning and then long term planning.

Available Time

There are a couple of things to consider here that can really sway how much development time you have. The first of them is the amount of time per day any individual on the team can devote to work, you have to remove time spent on waiting, emails, meetings and answering questions. I like to wrap that all into a standard inefficiency buffer of 10%, on any given day we lose an average of about an hour. From there you should also adjust down to take into account the amount of time spent on support/maintenance and juggling additional projects. But for the sake of this exercise, let’s say you don’t have to worry about either.

We do three-week development iterations followed by a week for meetings, integration and discovery. Let me explain why we decided on this cadence.

  • We only focus on the work at hand. Having planning meetings during an iteration removes some of the focus and also introduces some risk – i.e. having a planning meeting before your demos are signed off on can cause rework down the line.
  • We have issues with hand off. Most of the migration and set up tasks end up falling on the team. This might not normally be a problem but if you demo, get sign off and then go to migrate and find that there is additional work needed then you end up taking away from development time.
  • It provides time, albeit a short amount, to do any prep work before the next iteration. Again this is largely a result of those hand off issues but it helps ensure new projects don’t require a sprint zero to get started. We do still do spikes, sprint zero and go-live stories but at a smaller level than we would have otherwise.

All of those reasons aside, the math is what makes the most sense to me. Let’s compare a typical month for my team with this structure vs a standard two-week iteration with all of the meetings, integration and planning wrapped in.


If all integration work was handed off cleanly and we didn’t have to do much prep work to start an iteration, then we would look at changing the schedule. Or if we did integration less often, then we could schedule an integration sprint.

Short Term
We start every iteration planning meeting with a calendar and the stories we believe we’re going to tackle. The calendar shows PTO, holiday time and meetings or in other words our available time, what we have to start with. Then we review the stories and score them on a scale of 2-13; 2 is an easy story and/or something that can be done in just a few days while a 13 is something complex and/or might take the entire iteration. The maximum amount of points any developer is allotted is 20 but we only take a 20 if it has a lower amount of complexity and risk. Once the stories are done, we then task them all out.  We try to keep tasks fairly high level and at about 1 per day. For example, you may have a migrate database task instead of migrate tables, stored procedures, security, backups etc. Finally a review of the tasks vs the calendar to ensure that we all feel confident that we can accomplish it and then we commit to it.

That’s really it, short term planning in Agile is a breeze if you understand the bucket of time, your team’s relationship between time and points and how to best balance all of the above.

Long Term

With a combined load of support, enhancements and new development I do long term planning in yearly and quarterly increments – this does not replace release planning but assists with it by providing a high level overview of how resources are allocated. I take things like the on-call schedule into account and where holidays fall to look for conflicts. A good example of this is when projects are slated to go live – if the primary developer is slated to start a new project right away, it’s often not a big deal if the team is ready to take on support but if it’s new technology, new user groups or something out of the ordinary then we’d look to schedule the go-live during that developers on call to lessen the burden on the rest of the team.

The yearly plan looks something like this:




Typically, in December I map out everything I know of at the time on this sheet and then every quarter we review the upcoming quarter for new projects, date changes (including extensions), and then remove outdated projects and reshuffle for priority. At the yearly level I don’t care about points or releases, it’s more about dates and resources at a very high level. Release planning for me is specific to the product or project and therefore is a lower level detail than what I’m trying to accomplish with this plan.

My methods may differ some from a traditional SCRUM team; we juggle multiple projects every iteration, we support all of our products, and we change the plan on a regular basis. Given those differences, I believe that what we’ve come up with meets the needs of the team, our management structure and our stakeholders. An important thing to reiterate – this is how we do things now but should any of those factors change or if we were not performing as well as we do then we would take another look at how we do planning and adjust as needed.


Comments are closed.

%d bloggers like this: