According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.

Traditional Project Scope

Project Scope Management is one of the nine project management knowledge areas in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

Traditionally the scope of a software project has been defined in a specification document of some kind. Terminology varies considerably and the document might be called a requirements specification, functional specification, or program specification. Regardless of the name the document describes the function requirements, i.e. the intended behaviour of the system being developed, and the non-functional requirements that constrain the design or implementation (e.g. performance requirements, quality standards, etc). (See  Wikipedia: Software Requirements Specification (SRS) or Wikipedia: Functional Specification). These documents tend to be quite large.

Traditional requirements documentation can be characterised as both wide and deep, i.e. it covers the entire breath of requirements in considerable detail. The trouble with this approach is that generating such comprehensive documentation takes a lot of effort, and by the time the specification document is complete, it is also out of date.

And ironically in traditional project management any changes to the scope are seen as a threat to the project. Change Management is used to combat changes to scope.

Agile versus Traditional Project Scope

In an Agile project, as with traditional approaches, the scope defines what software to build and deliver. There are, however, several differences between the two approaches including the:

• Attitude towards change in Agile
• Documents defining the Agile project scope
• Timing of producing the Agile requirements
• Emphasis on high level requirements in Agile

Unlike the wide and deep requirements of the traditional approach, I characterise Agile requirements as high level and focussed. The scope of an Agile project is defined by high level requirements, in the form of User Stories, scheduled in the Release Plan. Detailed (or deep) requirements are still necessary but they are only created when they are needed – this is the focussed bit. That means that in Agile Project Initiation, the Product Owner produces User Stories for the entire project, but only produces supporting documentation for those User Stories scheduled into the first Timebox. During the first Timebox detailed supporting documentation is produced for the User Stories in the second Timebox, etc. This means that if/when the scope changes we have invested a minimal amount of energy in specifying out the bit that is no longer needed.

Whereas change is seen as the enemy of a traditional project and traditional Change Management is used to combat changes to scope, in the Agile world change is expected and Agile Change Management facilitates change. Seeing change as likely has an impact on the nature of the documents that define Agile project scope. Basically the documents have to be easy to change. In addition detail is left as late as possible to facilitate change. In the absence of detail the Agile Project Manager must use high level requirements, i.e. User Stories, as the basis of their Agile Project Planning.

Role of the Project Brief in Defining Scope

The Project Brief is a prerequisite for Agile Project Initiation. The Project Brief provides the context in which the User Stories are written.

Role of the Release Plan in Defining Scope

The Release Plan is the main deliverable from Agile Project Planning. It lists the User Stories that are in-scope and when they are scheduled for development. By implication it also indicates what is out-of-scope.

I find it very useful to have all User Stories, whether in-scope or out-of-scope, listed on the Release Plan. I flag the out-of-scope items as such as it is clear that they will not be built. This is mainly to avoid the inevitable discussion along the lines of

Product Owner: “But I asked for X”

Project Manager: “Yes you did, but you then deprioritised it to make room for story Y. We developed Story Y. Story X is out-of-scope”

This is an example of why Agile Change Management is important.

User Stories = High Level Requirements

User Stories seem to have become the defacto method for expressing high level user requirements in the Agile world. They originate in the XP world (Beck, 2000; Beck & Fowler, 2001), but the definitive work on writing user stories is “User Stories Applied” by Mike Cohn (2004).

User Stories are usually brief descriptions of the intended software behaviour from the user’s perspective. They can be brief because they are a place holder to a conversation between the Product Owner and the Agile Team and/or to supporting documentation.

User Stories are the base planning units used in Agile Project Planning.

Guidelines for Good Stories

Rachel Davies of Agile Experience advocates a user story format which is gaining increasing acceptance:

Story Title
As <role> I want <feature> so that <benefit>

This format not only tells the Agile Team what the feature is but which user needs it, and most importantly, why they need it.  The title is useful as a short hand for the rest of the story. I give each User Story a unique numeric ID as another form of short hand.

User Stories should avoid unnecessary detail, for example, they shouldn’t have details of the specific user interface. On the other hand it is essential that each story has at least one acceptance test associated with it before it reaches a Timebox to be developed.

Vertical versus Horizontal Slicing

Traditionally systems are planned and built by slicing up the work horizontally, component by component. As the work progresses the team adds extra building blocks to the product be they modules or classes.  This behaviour means that usable product features must wait until all the building blocks are in place before being ready, which might take several increments of the product.  This is problematic because the Product Owner cannot provide immediate feedback about the software until the full feature is delivered, long after the work started on it.

Agile uses vertical slicing. The software is built feature by feature, i.e. User Story by User Story. The Agile Team builds enough of each component (module or class) to meet the needs the User Story currently being worked on. That means the end of the Timebox, in the Timebox Review Meeting, there are more working features to be reviewed.  Instead of incrementally adding components the team is incrementally adding value. In this approach result, frequent feedback is possible to ensure that the software can evolve almost as quickly as the customer’s vision, maximising the chances that the customer actually gets the product they want.

Technical and Non-functional Requirements

This User Story format is useful for user oriented requirements but not for technical or non-functional requirements (performance, accuracy, portability, reusability, maintainability, interoperability, availability, usability, security, capacity). In these circumstances use whatever format is appropriate. For example, “The system must support peak usage of up to 50 concurrent users” or “Every page should load in less than 3 seconds”.

Splitting a User Story

There are at least three reasons to split a User Story:

• the story is an Epic, i.e. to too big to fit in a Timebox
• part of the story can’t be estimated
• part of the story has is higher priority (more value and/or more risky) than the rest

An Epic story is a User Story that is too large to be developed in a single Timebox. It is normal to have a few epic stories in the Release Plan, particularly at Agile Project Initiation, but these have to be split into smaller stories before the User Story reaches a Timebox for development.

Often User Stories include several separate functions. If there is some uncertainty about part of the User Story then cut this part out for investigation. The understood part of the User Story can get scheduled normally.

Similarly if part of a User Story is higher priority than the rest then the high priority element can be split out as a separate User Story for early scheduling.

Defects

Defects need to be logged just like enhancements which means as User Stories. The specifics of how teams do this varies. You have a choice:

• Log each Defect as a User Story
• Batch up several Defects as a single User Story

You then have the choice of scheduling the Defect User Stories like other User Stories or of having a reduced Velocity to cater for doing Defects. I tend to do the latter.

Where to Keep User Stories

Most commonly User Stories are written on index cards and are then pinned to a board. This approach has several advantages:

• It keeps the descriptions short
• It is cheap and easy to update existing stories, write new stories and/or discard outdated ones
• Anyone can write one, which gets everybody involved in planning meetings
• The board and the User Stories it contains becomes the focal point of discussion in the team

There are many Agilists who are happy to leave the User Stories on index cards but I prefer to have duplicate systems. Three in fact:

• As index cards on the board
• Titles and estimates in the Release Plan which is usually a spreadsheet (see Agile Project Planning, Agile Project Estimating)
• the titles at least in a task tracking database (see Agile Project Control)

There is an overhead to this but the different formats are for different reasons and I could never quite eliminate any one of them.

My Release Plans are always in a spreadsheet. Not only does this allow me to do some calculations on the data it contained (e.g. levelling team scheduled user Stories and Velocity/capacity) but it also means I can email the document to my customers. It is hard to email index cards.  If I had a specialist Agile project management tool such as VersionOne, Mingle, ScrumWorks, etc, I would consider abandoning the spreadsheet.

I also use a task tracking database containing the the tasks for each story. This facilitates sending out emails to individual developers and to the team as a whole, allows me to generate automatic release reports for the operations team and my customer, and gives us a history of what happened when which is important for support. Those specialist Agile project management tools (VersionOne, Mingle, ScrumWorks, etc) are ideal for this but there are other ways to achieve the same effect. At one company we just modified our call tracking system to be the task tracking database. Some of the other Agile teams I’ve managed prefer using a fault tracking database to the specialist tools because the fault tracking database has hooks into their source code repository (specifically Trac and Subversion).

Supporting Documentation

User Stories are not the only information on requirements. User Stories are a place holder to a conversation between the Product Owner and the Agile Team and/or to supporting documentation. If the Agile team doesn’t have sufficient information to estimate the work involved then the User Story needs further elaboration. In such a situation the Product Owner must provide additional documentation or models to help clarify particular User Stories. This documentation should be kept to a minimum but it shouldn’t be forgotten; XP recommends at most four pages of supporting documentation per User Story.

Typically this supporting documentation includes User Interaction Designs (wire frames), visual designs, or a combination of the two in a high fidelity prototype. Financial calculations also warrant being documented separately.

References

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

Cohn, M. (2004). User Stories Applied. Addison-Wesley.

Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide) [3rd Edition]. Author.