Fixed Scope or Fixed Goal?

A lot of people in the Agile world talk about 'fixed scope' projects. However, just how well aligned is the concept of fixed scope with Agile? Moreover, is it aligned at all and does the concept send out a contradictory and confusing message?

One of the things that we accept within Agile development is that requirements will emerge and evolve throughout the course of a project in line with our understanding of the problem and solution. This understanding is rooted in the Agile manifesto which tells us that we should value responding to change over following a plan.

Jonathan Rasmusson in his "The Agile Sumurai" book expands on this value by giving us the three simple truths of software development:

- You can't gather all the requirements up front
- The requirements you do gather will change
- There is always more to do than time and money will allow

I'm not sure that anyone involved in software development would disagree with any of those. So, if we accept these facts then surely we also accept that scope will change throughout the course of a project? If something changes then how can it be fixed?

What we really mean by a fixed scope project is that it isn't fixed by time, i.e. we're going to deliver something but there isn't a hard deadline for that fixed something to be delivered. The question is what that fixed 'something' represents. To explore this a little further we can look towards the different levels of Agile deliverable. Feature Injection outlines the following:

Vision > Goals > Capabilities > Features > Stories > Scenarios > Code

At the story level any typical project is likely to see lots of change. New ones emerge, existing stories change or are dropped altogether. At this level there is constant evolution.

The same is true for features, although perhaps to a lesser extent. If we consider features to be our high level stories or epics we also know that these are likely to change throughout the course of a project.

Capabilities are those things which will enable a business to achieve their goals. There's normally more than one way to achieve or contribute towards a goal and these are also open to change as we move through a project and learn more about the domain and requirements.

So what about the goal of a project? Although planned deliverables are likely to evolve the original goal or intention of the project is likely to stay the same, or ideally it would anyway. If the goal is continually changing then the 'project' is at best in support mode or at worst suffering from a lack of direction.

For example, a gaming website may undertake a project with the goal of increasing it's number of active users by 20% and there may be many ways in which to achieve this. We might have an initial view of the capabilities and features that we intend to deliver the goal but these will not just likely evolve but hopefully so as our understanding increases though learning from rapid feedback loops and validation of value. We may find, though validation, that a planned capability or feature is not contributing towards the goal of the project as intended. As a result of that validation we may well decide to amend that capability, focus efforts on building other capabilities or bring in entirely new capabilities.

Whatever the choice there will be an inevitable change in scope but the goal of the project will remain the same, and we'll be continually validating (hopefully) against that goal.

So when we talk about fixed scope should we really be talking about fixed goal? It does seem, at least, better aligned with the Agile concept of responding to change.