Tackling Scope Creep

Overview

Scope creep in reality is unavoidable, so your best bet is to have a good plan to identify and manage it so that your team and stakeholders stay happy.

Introduction

Traditional project management says that you can choose two of three options when completing work - time, quality or money. It’s said that having all three within a project is a fantasy because unknowns will always come in and force you to compromise on at least one of those three things. The most planned (waterfall) and the most adaptable (Agile) projects are all subject to scope creep; it can’t really be avoided. What matters is seeing this differently, planning for how you approach this and being transparent with each other.

What is scope creep?

Scope creep is when new features, functionality or unknowns are added without the impact being addressed. Most commonly, scope creep occurs because of:

expedited issues
lack of proper planning
misunderstanding of requirements
change of direction
unplanned for business as usual/maintenance tasks
things breaking or going wrong (often called “bugs”)
mismanagement of expectations or stakeholders

Part of being Agile is about adapting to changes - but this doesn’t mean scope creep doesn’t exist! Changing direction is fine, but there will still need to be compromises along the way.

Who can cause scope creep?

Honestly? Anyone and everyone!

Customers can create scope creep through their behaviour towards your product. A sudden change in consumer behaviour, or unexpected reaction, can make you pivot and incorporate new/different scope.

Stakeholders are similar to customers but they often have different agendas to the team and so are trying to solve a different problem. They can demand further features or changes to agreements after seeing a demo or first draft of a task. That’s the whole point of Agile, get feedback early and often before you produce something they do not want. Scope creep from stakeholders usually happens when you’re reviewing critical deliverables and/or hitting major milestones on a project. They shouldn’t be drastically changing the scope mid-project unless there’s a critical reason why; otherwise it can become a mess of expectations and a lack of trust will emerge between the team and stakeholders.

Project Managers, Product Owners, Delivery Managers or anyone else in the team’s leadership get pressure from above, other areas of the business and BAU tasks that suddenly need doing that always come up. They often feel they have no choice but to force them into the work cycle to appease colleagues or customers but also have to deliver what they agreed to their stakeholders.

The team always want to deliver their best work. They don’t want to cut corners, add to technical debt or make something rubbish so they will often try and fit the gold standard into what they’re doing. This is admirable but also has an impact on the whole team. Everyone wants to do their best and will often go off piste to accommodate issues, but if this starts making work more difficult than previously understood (re-estimation should occur if you’re using points) then this should be discussed as a team so you can agree to any fallout as a result.

You should always aim to deliver value as early as possible, and this means resisting the temptation to get it perfect, instead delivering and then iterating on the product, this also helps you build trust.

Why is scope change unavoidable?

Most of the time, you don’t know all the unknowns until work begins - particularly in software development. What was thought to be a simple task might have a system you haven’t worked with or the only person who can approve the copy is off on holiday for a week.

We also shouldn’t be surprised that a talented team will want to improve and innovate on proposed solutions as the work is taking place. In fact, if the team doesn’t try to improve on the proposed solution then something is probably wrong in the process or with the people within that team. The trick here is to be aware when this is happening and have a plan to manage it.

Identifying and dealing with scope creep

If you use Scrum, a burnup chart is the simplest way to check on your scope (Jira makes this easy to access). A burnup chart quickly identifies where you’re going off track and you can read about where this is and how to read it on our Jira Metrics page.

This chart does only work if you’re working in Sprints, but you don’t have to be estimating as you can analyse using issue count instead. Teams working in a Kanban structure or without Jira can still keep an eye on scope creep by seeing what tickets are in progress or to do and seeing how long it’s taking for them to be completed and why they keep being bumped down the priority list (staying in one column for a long time usually indicates that other work is superseding it).

Once you’ve identified there’s a problem, you need a plan of how to deal with it. Traditionally change is avoided on software projects because of the likelihood it will incur a high cost later on. Agile challenges this notion and believes the cost of change can be relatively flat, but there are still compromises that need to be made.

Focus on the goal - your sprint/cycle goal will define what’s in scope and what’s not. If it’s not adding to that goal, reject the work.
Remove other work - it’s great to adapt, but something else needs to give. Take other commitments out and don’t overload the team.
Flex your scope - it’s far better to know that scope creep is inevitable. That way you can plan for it and not be hijacked by it. Try setting aside 10% of the time as “flex” that will account for healthy scope creep.

Once you’ve accepted that scope creep is inevitable, you and your team can help work out when it’s a good thing and can add value to the project and when it’s just a distraction from your main goals.

Summary

Healthy scope creep is often where the amazing things happen; where bigger problems get solved and new ideas are born. It’s up to great leads to create the conditions that nurture this good kind of creep whilst protecting the team from the bad kind. Great teams welcome changes and successful ones communicate well when and why the team needs to pivot in another direction.

Further Resources

Scope Creep: Causes & How to Control in Project Management
For Holiday Extras employees, the Agile Coaches have a Scope Creep workshop we can run for you and your team - get in touch if you'd like more information

Report abuse