How to reduce developer scope creep

You hopefully already know that as a project manager, you should not be initiating or contributing to scope creep. Your development team already know that you as PM are not allowed to let scope creep happen so they push back if you try – and quite rightly so.

However, what happens when developers create their own scope creep? They raise an annoying bug they found and you give the okay for it to be brought into a sprint and fixed. But unbeknownst to you, they turn it into a bug fix that includes an all singing and dancing new UI because “it was outdated and they were already in that part of the code anyway”. They didn’t ask you or anybody else on their team if it was okay to do, they didn’t raise a new separate ticket for the work, they didn’t even mention they were doing it in their daily stand ups. Why? Because they know it’s wrong. Or do they?

From experience there seems to be a very blurred line for some developers in some companies I’ve worked at who don’t think that the rules you as a PM must follow, apply to them. They don’t realise that it’s a two way street that you all must collaboratively cross and this isn’t because of authority, ego or management. It’s because of trust. You and every member of your team must have a mutual level of trust in everything that you do. Trust that you will all be honest, accountable and respectful to yourselves and each other. Scope creep goes against that trust, regardless of which direction it comes from.

So, how can you avoid developer scope creep? You keep your end of the trust bargain and you be honest with them about why its not acceptable. Explain that you understand why they did it, after all the UI could do with being brought into the 21st century and they were in that part of the code anyway, right? But ask them how they would feel if you had been the one to request they add on this extra improvement to the feature when they were simply supposed to be fixing a bug. Would they be mad? Would they bring up “that time you asked them to do one thing and then added on four extra requirements that weren’t initially agreed on” in the next retrospective? Would they start rolling their eyes every time you ask them to do something because they’re already preparing themselves for you to later say “oh and one more thing”? If they answer yes to one or more of these then they already understand what they did was wrong, they just hoped they wouldn’t be held as accountable for doing it as you would be.

You must be careful though not to come across as saying that what they did was wrong, it’s simply how they did it that caused you to raise your concerns. They likely saw themselves as being proactive and efficient by improving something rather than just fixing it to make it work correctly. Under no circumstances do you want to dull their want to be proactive or efficient – these are skills you want to encourage and help them develop. It’s part of your job to help them understand how to approach these situations and the best way to achieve that is empathy.

Humans are full of empathy, it is both a blessing and a curse but we can’t help it! Ask them to put their opinion to one side and try to validate yours for just a moment instead. Be sure that they know you’re not necessarily asking them to agree with your opinion, you’re just asking them to acknowledge it. I.e. “I did it because I was already in that part of the code and it seemed logical to me but I understand how that counts as scope creep and could have a negative effect on sprint velocity”. Ask them to listen to the wider picture of what you’re trying to say – scope creep reduces trust and morale amongst the team, creating potential conflicts such as QA requiring lengthy regression tests which weren’t anticipated based on the original remit of the work.

Enable your teams to understand why a simple extra unplanned piece of work (albeit one which is a valid contribution) can be detrimental to the sprint, the team and your relationship. Enable your teams to understand that you’re not disallowing the work because you’re a maniac who doesn’t believe in product improvement. Enable your teams to understand that you respect them enough to not increase scope part way through work and you expect the same in return.

If you liked this story, please share and recommend to others. There’s plenty more where this came from!