How to measure scope change?

Question

Is there a way to somewhat-objectively measure changes to project scope? Our team (a new PMO) is looking for a way to measure how much the projects we manage change over time. How can we measure changes to the actual project scope (beyond a basic "project X had Y formal change requests").

We can measure changes to time-to-delivery or resources in general, but that can change even when scope remains the same - we want to be able to isolate the impacts of true scope change (i.e. add another feature, or create a new customer support process), not just missed deadlines or misestimated resources.

For additional context, we're a product-driven org, but we want to track full project scope, not just product scope.

Answer 1

Scope change can be measured using project management software such as Jira.

• Perform an initial scoping exercise with the team at outset, and create tickets in the project management software. Create the tickets as individual user stories that are capable of being reasonably accurately estimated using story points.
• Collect the tickets into a backlog in a separate, named project.
• Have the team estimate all the tickets using story points. I like to use PERT for this, although you can use a variety of techniques including Planning Poker.
• Now that you have all your tickets estimated, just total the number of story points associated with the project, and you have your scope baseline as an integer number.
• Begin project activities, putting tickets from the backlog into sprints or Kanban. As scope changes, new tickets will need to be added, or existing tickets will be re-estimated.
• Periodically you can re-total the story points for the project to see how much the total has changed. If you started with 100 story points and now you have 125 story points, you can say that scope has increased by 25%.

The advantage of this method is that scope change can be measured on-the-fly at any time even as the project is in progress.

The potential problem is that you are not measuring scope increase but the inability of people to estimate tasks accurately. That's going to be true to a certain extent, but using a more reliable estimation method like PERT helps to alleviate estimation errors.

And besides, scope change and estimation error are closely related to the point where it is sometimes very difficult to tell them apart. But certainly the appearance of new tickets that were absent at outset (true scope change) will be noticeable, and now you have a tool to measure the resulting scope change.

Answer 2

A burn-up chart measures and visualizes project scope change separately from project progress. A good reason for doing this is to identify changing trends in real productivity (velocity) more accurately.

Answer 3

Scope change can be measured by change in budget and time. Some changes occur without a change in budget or time because perhaps there was an offset with another change; however, all changes should be estimated for that change in budget or time whether or not the contract actually changed. If that is tracked, then you have the data you need to measure scope change.

Answer 4

The original scope has a value. You earn that value over time. That is Earned Value. Your approved scope changes add to or deduct from original scope. You can measure it in dollars. Once you quantify a scope change in terms of dollars, the rest is straightforward earned value calculations