«    »

Meeting Milestones via Swarming and Reserves

No matter what method of software development a team uses, there will be times when the team struggles to meet planned milestones. The milestone could be completing committed stories for an iteration or reaching the feature-complete point in a release. The struggle to meet the milestone might be caused by any number of factors like requirements churn, poor quality work, or insufficient resources. Whatever the cause, the question facing the team is how will they meet their milestone?

I have faced this problem yet again recently and wanted to share two approaches that I have found useful: swarming and reserves.


The basic idea behind swarming is to throw extra people at the outstanding work necessary to meet the milestone. In project management terms this typically involves sacrificing effort (budget) to save time (schedule). Effort is typically sacrificed due to two factors. First, more than the optimal number of people are working on one piece of work and some effort is lost through extra coordination. Second, people get involved doing work outside their normal expertise and thus require more time than normal.

An example of swarming is a scrum team pulling together at the end of an iteration to finish their committed stories. Developers could pair up to more quickly resolve the remaining defects. Once done testing their own functionality testers could jump in to help test other features they are unfamiliar with. Business analysts can delay working on future requirements to help test.

There are a couple of guidelines to swarming effectively. The first is to focus on the critical path - the activities that are predicted to take the longest and drive what the final completion date will be. This is typically accomplished by pulling people off of non-critical-path activities, but you have to be careful that you do not inadvertently slow down something else so much that it then becomes critical path.

The second guideline is similar: focus on work necessary for completing the milestone instead of non-milestone-related work. This may seem obvious, but in practice it is surprising how people will tend to choose the more interesting tasks over more tedious but necessary tasks (for example, updating end-user documentation prior to release). One way of achieving this focus is to clearly define what is part of the milestone versus what is not. One team I know uses a task board with post-it notes colored by release to visualize this.

Swarming only works when you have people on the team who are available to swarm - i.e. not all busy on critical path and/or milestone work. This leads us to the topic of reserves.


The basic idea behind reserves is to hold back a portion of some type of resource so that it is available if an unforeseen situation arises - usually a problem, or sometimes an opportunity.

One very common approach is to set aside a period of time in the schedule as contingency. This may be an extra iteration per release, an end-of-release iteration to finalize the software for release, or simply extending the original estimated schedule by a certain percentage.

Another approach is to ensure that the team members are working normal hours - i.e. no overtime. If a time crunch does occur, then a short burst of overtime acts as a reserve. You have to be careful using this approach, as too much overtime is dangerous. You need to allow time for recovery afterwards, once the milestone is met, or risk disengagement, reduction in productivity, burnout, and loss of personnel.

A more advanced version of this approach is to ensure that each person is not normally 100% busy, as espoused by the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. It is suspected that this is one of the reasons that companies such as Google provides 20% time for each employee to pursue personal projects. The first benefit of slack is that this minimizes time to completion by reducing delays due to work waiting in queues (as per lean theory). This thus reduces the chance of needing to struggle to meet a milestone in the first place. The second benefit is that, like overtime, people have the capacity to increase their efforts if a milestone is threatened

A related approach that has worked well in my own experience is to have some project members normally be assigned part time with flexibility in how they spend their non-project time. During crunch periods they can then easily increase the percentage of time they spend on project work.

I would like to hear your experiences regarding swarming and maintaining reserves - please share by leaving a comment.

If you find this article helpful, please make a donation.

«    »