It’s a common misconception that agile processes can’t be used with fixed scope. But a misconception is exactly what it is. A number of the founders of the agile movement developed their forms of agile on fixed-scope projects. As I write this, I’m working myself on an 18-month project with about 20 people and a fixed(ish) scope (see below). So it can be done. But how?
There are several different strategies you can use:
Strategy 1: Fix the scope and flex the price
This keeps scope management very simple, you just build all of it. The catch is it may take longer than you expected, so you may need to flex the price through a time-and-materials contract or some kind of sharing of financial risk. Understandably, this risk of cost overruns renders this simple approach unsuitable in many environments.
Strategy 2: Work in priority order and stop when the money runs out
(Admittedly, this is not exactly fixed scope.) This is very commonly recommended on agile projects, too commonly in my opinion. But again, it has the virtue of being relatively simple. Do the most beneficial stuff first, leaving the least beneficial until last. When the money runs out, just stop and don’t do the rest. Agile makes this approach possible – but not mandatory.
Strategy 3: Implement remaining features more simply when short of time
There are many factors that influence the effort required to develop a feature (or user story, depending on your terminology). Some of those factors are probably under your control: e.g. How extensive is the validation? How much effort do we put into optimising the user experience (UX) and appearance? Do we fully automate everything, or do we allow manual overrides so we don’t have to code every single edge case? Can we think of something that would save development time, and still meet the overall business goal (albeit in a different way from what was originally expected)?
If you are using good earned value tracking you should know, within the first quarter of the project, whether you are likely to run out of time at the end. Once you find that out, immediately start seizing all these opportunities to simplify the remaining 75% of the project. And, because you have good earned value tracking, you can justify the simplifications to your stakeholders. The aim is to deliver all of the planned business benefits, just with simpler implementations than might have been originally expected.
We’re using a variant of this strategy on my current project. We built the highly-used parts of the system first, taking a lot of care with their appearance and usability. The second half of the project consists of functionality that is much less commonly used, so here usability and appearance are much less important. (If it takes a user a few extra minutes to do something, it doesn’t really matter if they only do that thing a few times each year.) So for the second half of the project, we have consciously shifted our design approach away from ease of use, and towards simplicity of implementation. Because we were using earned value-like tracking, we can justify this change of approach to users and management.
Strategy 4: Split each feature (or user story) into essential and nice-to-have parts
This a refinement of the previous strategy. Right from the start of the project, you split features/user stories into two pieces: an essential minimum piece, which you implement early, and nice-to-have embellishments (such as advanced data validation or visual styling) which you defer to the tail end of the project. If you run out of time, you drop some of the embellishments from the tail, and still deliver a working system with the full scope of capability/functionality.
Strategy 5: Make multiple passes over each story, doing the basics first and then improving it later
Similar to strategy 4, but you may “visit” a given user story 3 or more times within the project, instead of just twice as in Strategy 4. I like this in theory, but in practice I think it’s too hard to used earned value or burn-chart tracking in this strategy. Whereas in strategy 4, I feel that earned value remains (just) feasible.
[Tim Wright's comment, below, gives more details on how this strategy can be done]
Summary
The last three strategies are all variations on a theme. Within a single project, you may use several of them, and maybe also resort to strategy 2 for a few user stories.
I recently heard the phrase “value management” to describe the work of deciding not only what to build, but also how simply or thoroughly to build it The aim is to meet the business goals with the optimal expenditure of effort – i.e. do what needs to be done, without overspending on superfluous details.
Further Reading
All of the following are excellent.
Alistair Cockburn’s Trim the Tail. A rich explanation of the theory and practice of strategies 4 and 5, with significant additional benefits in risk management.
Alistair’s list of related strategies.
Jeff Patton’s concept of Feature Thinning: Jeff’s a leading practitioner of Strategy 5. See: Finish on time by managing scale, Difference between incremental and iterative, Accurate estimation = red herring Jeff has often used these techniques on fixed-scope, fixed-price projects.
Description from an agile company called Atomic Object, of how they operate with fixed budget and controlled (rather than fixed): here and here.
Martin Fowler’s Scope Limbering
The opening section my my own agile earned value (pdf) has more info on why fixed scope is a valid option in agile.
I’ve also posted a summary of estimation tips for agile projects.