Agile Project Management – The Dreaded Scope Creep

So, what are your thoughts on scope creep? Not a big fan? Well you are not alone.

Scope creep is that unfortunate, but very common part of a project where the scope of the project keeps growing and changing after the project has already begun. As experienced project managers we need to be honest about how scope creep happens and consider how Agile Project Management techniques, like the Value Pyramid, can be used to manage it.

The birth of a project’s scope

You probably know better than anyone how a project’s scope is defined. The process goes something like this: You identify the stakeholders, record their requirements, make a prioritized list, create a work breakdown structure and activity list, and put in place a change management plan or process… next thing you know, scope is defined. But then you’re left to wonder. You wonder how much is going to change.

The birth of a scope creep

Once the activity list is created, it is easy to drive the project and stick to the list. The question is, will those activities bring the needed value to your stakeholders? The key words here are bring value. Requirements are interesting, but unless they bring value they are not meaningful. The number one reason for scope creep is assuming that answering the stakeholder’s requirements automatically delivers the value they’re looking for. When your “client” realizes that their goals will not be met, their requirements change, again, and again. And scope changes and scope creep begins.

Concentrate on value, not scope

So, what can we do differently? To begin we have to start by looking at requirements through a goals and values lens: What are the stakeholder’s goals and what value are they looking to gain from accomplishing them?

1. What will this project help and how?
2. To whom will it help?
3. In what way?
4. What does your stakeholder need to do to gain value from the project?

After you understand what the value you are asked to create is, you are ready to move to the next phase of prioritizing what value pieces are more important than others. This is key. Your project might miss deadlines, budget, or initial scope (value), but if value is always the priority, you will be able to deliver the important pieces that will drive it. I will not get into the details of how to prioritize and manage requirements, but I do want to get into value management and its relationship with scope creep.

Value Creep

While scope creep happens every time the business requirements change, value creep rarely happens.

Normally, it is the how we get value from a project that changes. The tasks, user stories, and acceptance criteria, if not built on a business value base, will almost always change. Yes, it is easier to manage a task list and harder to control value creation, especially in an environment of conflicting goals, but presenting progress numbers (e.g. we worked 430 hours and have 150 to go, we are 78% to completion, etc.) only pushes those conflicts to later stages where changes are expensive.

Value conflicts need to be addressed as early in the project as possible, in the Minimum Viable Product (MVP), i.e. when the product has been built with enough features to solve the basics of the problem - that brings me to the next topic.

Value Pyramid

The Value Pyramid is an Agile Project Management technique that is like the roadmap behind building products/solutions. The main goal of the pyramid is to help in organizing and prioritizing each step of the project’s development cycle and the value that lays behind each step. 

As a project manager, one needs to integrate the Value Pyramid by placing the right borders around the question “What should we do next?” This is even more important on projects where corporate standards need to be followed as this can add complexity to how a project needs to be managed and how value is pereceived.

With all of this in mind, lets break down the first two layers of the Value Pyramid and see just how they can help you prevent scope creep on your next project.

Layer 1 - Business Problem Solving Enablers:

The first layer, Business Problem Solving Enablers, looks at what needs to be done or built to solve the problem. It will have high-level designs, infrastructure, specific tools that were not used before, and training or new domain exploration before diving into the solution. The activities may not seem to add value to the business, but they do. They expose the roots of the problem, and why that problem was not solved before when the enablers were not in place.

Layer 2 - Solving the Problem:

For those familiar with the term MVP mentioned earlier, you should note that establishing the MVP is the goal of the “Solving the Problem” layer. Basically, the business should be able to use the MVP as a temporary solution to the problem.

The purpose of these two layers is to prove two things: The first is that the Business Problem is solvable by the proposed solution or product because there is no point working on products the business will not use. The second proof is related to our initial estimation, typically the MVP should be built about half way in the project, for resources and schedule. It will validate the value and business needs, and affirm that we should not expect significant changes after this layer as the MVP solves the problem the project was supposed to address.

As you can see, we have only covered the first two layers of the Value Pyramid and how they apply to Agile Project Management and scope creep. If you would like to continue the conversation on Agile Project Management and the Value Pyramid, feel free to leave a comment below. To learn more about Online’s Business Consulting practice, click here.