I both embrace change and also fight like crazy to reduce scope creep. On my current programme I use three main techniques to control scope: Programme Vision, Release Goal, and Requirements Trade-off. In different ways all of these put the business in control of what is in/out of scope. But they all help me stay within budget and time constraints.
My current programme has the usual mix of product development and business change. Ambitions are grand but we don’t really know what the final product could, should or will look like. Nor should we at this stage. I have to encourage ideas. Encourage innovation. And accept that the business will change their minds and go a different way.
On the other hand I’ve got a hard deadline and a fixed budget. So my only flex is in scope. And my only chance to achieve success, with limited time and money, is to control scope. The smaller the scope the greater my chance of success.
Programme Vision
I pushed really hard on my current programme to get a Programme Vision Statement. This is a one liner. The one line to use when people ask “what is the programme for?”
I can’t share the vision of my current programme so I’ll reuse the example from my previous post. This was for an educational institution. I reframed their vision as:
We help Shani study any language, from anywhere in the world, at any pace she chooses.
Having this vision is fantastic for controlling scope. Now when people suggest a feature I can ask whether it helps us achieve the vision. In the case of the educational institution I would ask “Does this help Shani study any language, from anywhere in the world, at any pace she chooses?” If the answer is “no” then the proposed feature is out of scope.
Applying this approach in my current programme had an immediate effect. It drastically cut the number of features being proposed and helped us concentrate on identifying and delivering the minimum viable product.
Release Goal
I normally don’t bother identifying release goals as part of Release Planning. However, on my current programme it was useful to give the minimum viable product a one line description. We also gave the second group of epics a name as well. These are not the real examples but give you an idea of how that worked:
- National manual scheduling
- Automated scheduling
- Other stuff
These names captured the essence of those releases and again helped us decide on relative priorities. If a user story helped with “National manual scheduling” then it was high priority – potentially part of the minimum viable product. If it was more an automated thing then it was lower priority. Anything else wasn’t important, at least to start with.
What was most interesting about these release goals it that they changed. We realised the approach was wrong and given the real gold was in automation we needed to emphasise that. In the new world the manual approach was going to be discouraged so why make it a priority for development. The new release goals and associated priorities were the equivalent of:
- National Automated scheduling
- Enablers for manual scheduling
- Other stuff
Requirements Trade-off
Requirements Trade-off is the main technique I use to allow me to both embrace change and control scope, i.e. to manage change. In Requirements Trade-off the Product Owner swaps User Stories in and out of the Release Plan to ensure the total size is unchanged. If the Product Owner wants a new User Story, because it is higher priority than other User Stories, they can add it to the Release Plan only if they drop something else.
The total estimate for all User Stories doesn’t increase so the new User Story can be no bigger than the old User Story it replaces. This sort of change doesn’t threaten the project as the total cost and time should be unchanged. Obviously new User Stories need to estimated (see Agile Project Estimating).