March 23, 2013 | John Rusk | 4 Comments It’s a common misconception that agile processes can’t be used with fixed scope. A number of the founders of the agile movement invented 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 (“Feature Thinning”) 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 (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 opportunities to simplify the remaining 75% of the project. 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 this second half of the project, we have consciously shifted our design approach away from ease of use and towards simplicity of implementation. Because we are 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 (aka Managing Scale): Jeff’s a leading practitioner of Strategies 3, 4 & 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) scope: 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.
Hi John, There is another spin on strategy 5. Build the system so that each feature has a “C” grade (ie: it passes but isn’t great). Then iterate and build up features to B or A (or even A+ for some critical features) across the entire feature space – delivering enhanced value to all stakeholders. For example, you might split a story “create order” into “create order with mouse” and “create order with keyboard” and only deliver the second if time permits. Jeff Patton’s user story map is a good technique to help with this. That example of mouse and keyboard is one that Jeff has actually used on a project. Tim
A sprint was called a “timebox” in some early methodolgies such as Catalyst We also had spirals in other methodolgies. We were able to do EVM by recoginizing favorable cost variance when we pulled additional scope into the work period and unfavorable cost variance when we moved work out of the cost variance. The original scope was accompanied by an estimate of the number of time boxes or spirals neccessary. A periodic LRE (latest revised estimate) was based on the view of the number of remaining cycles (be they spirals, timboxes or sprints) to implement the remaining high level requirements. Some teams balk at the concept of spending the exactly planned funds and having a cost variance because they adjusted the work content for the time period. Earned value has always been able to deal with such baseline changes. Many agile/Scrum authors use burndown charts. Establishing a value for each story and for technical debt that is part of a sprint is doable. Measuring at the end whether you did planned scope/more scope/less scope allows EVM to be applied to compute a cost variance for the work actually performed, Jerry
Thanks Jerry. (And sorry for my tardy reply). Did the approach you describe require some degree of up-front planning of which work would be done in each timebox? I suspect I’d find that difficult on the projects I’m involved with. What I’ve tended to do instead is to just track completion of stories to compute EV (aka agile “burn”). The only pre-requisites are to have a list of all the stories which you think will be in the project, and to (roughly) size them all. The particular timebox into which a story falls doesn’t need to be planned and, in the approach I’ve used, doesn’t actually figure in the EV calculations. I’d be interested to hear any further thoughts you may have on the various ways of approaching this.