The scariest point of any project – that moment when new scope creeps in. This happens everywhere – scope creep in Agile projects is a very serious reality. And then what happens….
- Unrealistic expectations are set.
- Frustrations and tension rise.
- Someone says that it’s the Agile way of working – to accept changing requirements…
How do you handle it?
Well, I have a few insights to share with you. Watch the video or keep reading!
Let’s build some awesome teams… who can magically complete all of the scope creep before the deadline!
Ok, these are some unrealistic expectations right there.
What I mean is that there isn’t a magic solution that will make everyone happy and will make all of your problems go away.
I know that’s what people are looking for, but I’m just being honest with you.
Hmmm, then what can you do?
Three words: inspect and adapt.
Basically, review how new scope is affecting your plans and adjust them accordingly.
And, of course, I have actionable advice for you in this video that you can implement in your situation right away.
Keep reading….
Here’s what you need to know going into this:
- first, your initial plans are very likely to be INCORRECT anyway
- second, changes in requirements WILL happen because of the nature of work your team does
- and third, managing score creep is NOT about making magic happen, it’s about setting the right expectations
So let’s see how you apply this knowledge in practice.
But before I continue, as always, you know it already – if you are not subscribed (and I know that over 70% of you aren’t), remember to click that subscribe button below as well as that notification bell to never miss a video from me.
Ok, scope creep, magic solutions, setting expectations.
Should scope creep be expected?
You might be wondering – is the goal here to be able to MANAGE the scope creep or to AVOID it altogether?
And if you are working with software or just new product development, you will not be able to just avoid all scope creep.
And if you DO focus on that avoidance too much, then you are not really helping your product long-term. You’re just setting it up for failure.
When we work with complex products (such as software), we must expect changes because there are many factors that may impact our success and our progress.
And I don’t mean someone has a shiny object syndrome and just wants something just because.
I mean… here are a few VALID reasons for making changes to your plans:
- The solution or technology you initially wanted to use is found to be too costly to implement, in terms of money, time or effort
- A feature or capability you planned to build turned out to be irrelevant to the users
- There is a major issue in the product that has to be addressed asap because the product is unusable otherwise
If you don’t change in these situations and just blindly follow your initial plan, you are putting your whole product at risk. And also wasting your team’s time and company’s money.
So it’s not about avoiding scope creep, it’s about managing it properly.
I talk about this topic in my Product Owner guide that you can find in the store.
That whole concept comes from the difference between product and project thinking.
Just to make sure we’re on the same page:
What’s scope creep?
From Wikipedia:
Scope creep in project management refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful.
From the team point of view, scope creep means that the team is asked to do much more work without any changes to the deadlines.
First thing to do when scope creep happens…
…is to identify if that scope creep is valid.
As I mentioned earlier, there are some reasons that would make changes to your initial plans required.
However, there are other reasons that don’t validate those changes.
So your first action when scope creep happens is to investigate it and identify the reasoning behind it.
You will need to review your current Product Backlog, your current plan, and see how that new scope compares to everything else you have.
One big question to ask:
Is this new scope more important than EVERYTHING else in our Product Backlog?
If not, then a follow up question:
Is this new scope more important than SOME of the work planned in our Product Backlog?
To know what’s more important you need to have some kind of criteria or even simple metrics in place.
ATTENTION!
Just because something is urgent it doesn’t mean it is automatically important.
……. How is that possible?
Let’s say I’m working on a new guide to launch in my store by the end of the week.
This is a money generating opportunity from a business stand point.
And suddenly I receive an invite to, say a meetup, but I have to reply and prepare a presentation for it this week.
It’s urgent – I need to do it now, or I won’t do it at all.
This is a business decision to make: which is more important – the new guide or the meetup?
Initially it might seem that I must work on that urgent task first, since it’s urgent.
And this is usually how many companies operate.
However, from a business point of view, if I postpone the launch of a new product, I will suffer a greater opportunity cost as I will be losing potential business revenue.
While this task was urgent, it was less important than whatever I had in my Product Backlog.
…maybe that meetup will invite me back in the future???
Btw, I’ve talked about it and shared a useful decision matrix for teams in one of my older videos called “Time management and prioritization for Scrum teams”.
For the sake of this video, let’s say we have some new scope that we have identified as more important than what we have in our Product Backlog.
The next step to take here is…
…to decide what will we change: move the deadline or reduce the initial scope.
I know what you’ll hear (or say yourself): we can’t change the deadline and we can’t change the initial scope.
Ok, got it.
Here is what’s going to happen:
If you add something new into your backlog, you need to make some changes to your plan:
- either you extend your timeline to accommodate for that new work;
- or you remove something of similar size from your backlog.
This is another important business decision to make, and it needs to be made by whoever is accountable for the outcome.
So either your Product Owner, or your stakeholders in the absense of one.
Another big question here: What is more important for us in this milestone – getting it done before a certain date or building a set amount of features?
Just remember, “both” is not an answer. This is a binary type of question.
Why it’s not an answer? Because we are not magicians.
Realistically, no matter how hard you try to fit more work into the same capacity, you won’t be able to achieve the expected result.
Everything in this situation is a trade-off.
……
I realised, that you actually do have the third answer. Here are your choices:
- Add new scope, move the delivery date
- Keep the deadline, remove something of similar size from initial scope
- Try to cram in more scope into the same timeline, and get a crappy product and lose your team
If you push the team to do that third option, what will most likely happen is that you’ll get poor quality deliverables and exhausted people who lost all motivation.
The choice is yours.
Whether you choose option 1 or 2 (cause of course you won’t be choosing number 3, right?), you will need to do some estimating and forecasting.
If you decided to move the date further out, you would need to estimate the new scope and identify the new likely delivery date based on the progress the team has done so far.
This is still not a guarantee, but it is much more realistic.
We are setting expectations, remember?
If you decided to remove some scope, than you would still may need to estimate, but you will also need to do some additional prioritization.
You would need to decide what is less important in your initial list of work, and also remove enough work to accomodate for that new stuff you are adding.
And yes, you guessed it, it’s still not a guarantee, just more realistic forecasts.
What you need to do when scope creep happens
Let’s talk about how it might be impacting you and your role in the organization.
Scrum Masters
If you are a Scrum Master, you will most likely need to do a lot of teaching and coaching on that concept of forecasting and changing plans.
You need to help others understand how we plan in a complex business environment and how apply the principles of empiricism to our work.
As the Scrum Guide 2020 highlight one of the potential Scrum Master responsibilities is:
“Helping establish empirical product planning for a complex environment;” and “Helping employees and stakeholders understand and enact an empirical approach for complex work;”
If that all sound like a complete gibberish, you’ll need to work on that and build the knowledge needed to teach others.
And for that I have a great online course available – the Fundamentals of Agile.
I have specifically designed it to help you become an exprert in complex Agile concepts and be able to apply them in real life.
Product Owners
If you are a Product Owner, you will most likely need to work closely with your stakeholders to give them visibility into the team’s progress as well as communicate any changes as soon as they happen.
This will require good negotiation and mediation skills as you might be making some stakeholders quite unhappy with your Agile approach to planning.
You will also need to implement some good metrics that will help you make decisions around what scope change should or shouldn’t happen.
In addition, having a toolset of great prioritization techniques, especially, if you have several different stakeholders that might not be agreeing with each other.
Team Members
If you are a team member, you will need to understand the empirical approach to planning in a complex environment yourself.
This would include knowing relative estimation techniques used in Agile.
You will also should be comfortable with uncertainty as you will need to make some decisions without having all of the possible information.
Basically, be able to avoid analysis paralysis.
And then, you most likely will need to communicate with stakeholders from time to time when new scope comes your way and have courage to say “No”.
Managers & Stakeholders
And, if you are a manager or a stakeholder, you should be aware of planning and forecasting approach in a complex environment.
Or maybe, seek out your Scrum Master to help you understand it.
You will need to have courage to trust your team, even if you maybe don’t have that trust yet.
You need to set up good goals and be open to changes in scope or deadlines.
You must reduce the command-and-control management approach to a minimum (or eliminate it completely).
Since you are most likely will be the person directly working with the customer, you need to know how to negotiate and communicate with them when changes happen in a productive way.
As you can see, everybody has a role to play when it comes to scope creep.
Summary
Let’s do a quick summary of what we have covered in this video:
- You shouldn’t be avoiding scope creep, but instead learn how to manage it properly.
- When scope creep happens, the first action is to identify if it is valid.
- Then, decide whether you are going to move the deadline or reduce the initial scope.
- And, communicate the changes to everyone who might be impacted by it as soon as possible.