How to measure scope change?



  • 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.



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2