Here is a common question I get regularly. In this case it was Howard, a co-worker from the UK: “Probably a dumb question but…how do you define scope yet remain agile? Is it woolly wording, do you define it using some kind of abstraction or do you define in terms of number of iterations? The key being that, in my experience, most people what some idea of what they’re getting up front, yet in remaining agile we want to defer that sort of decision until later.” This is not at all a dumb question because it identifies the key difference between agile and traditional project delivery. Here is my response to the questions.
In my projects scope is a matter of defining this at the right abstraction level, or maybe more precise defining it without much detail. First thing you need is an concrete idea about the project’s scope boundaries. You can use the business case and vision for this purpose. They should provide the constrains with respect to for example business processes to support or available time and budget.
Next step is to make a first inventory of the functionality to be developed. You can use a business process model and/or use case model for this purpose. At this point in time you only define the outline for each process and/or use case with just enough detail to get a general idea about it’s function in the process and a preliminary idea of the complexity, i.e. the expected cost for the realization. This provides both a general idea of what will be build at what cost. This is the infamous backlog everybody is talking about.
And to make the project delivery agile, here is the key point: The project team has to be willing to change the content of the backlog as the project gets along, more detailed information about the problem at hand comes available and the client’s needs change. And this change actually should be exchange. If a new backlog item is identified this should be exchanged by a low priority backlog item we thought we would up front. You probably do want to keep the cost for the project constant or otherwise you need to find you a sponsor for new backlog items.
This is also the reason backlog grooming is so important. The team should keep the backlog up to date and the high priority backlog items should be more detailed than those with low priority. This constant reevaluation of the backlog in collaboration with the client is your guarantee you will actually deliver the solution the client actually needs and not the solution he thought he needed at the start.
So bottom line: you do need to set a scope for a project, but only with just enough detail to get an initial cost estimate and budget. And if you want to deliver the project agile, both you and the client must willing exchange low priority backlog items with newly discovered functionality which has a higher priority or value to the client, keeping project cost constant.