DEV Community

Valentin Sawadski (he/him)
Valentin Sawadski (he/him)

Posted on

Handle scope changes without coming across as a naysayer πŸ™Œ

XKCD Comic Strip Showing a Product Manager and Developer, talking about introducing scope changes to a Software

Sooner or later, every developer finds themselves in this situation where "simple" scope changes are introduced in the project. Instead of saying "No!" to those changes, let’s learn some communication skills today: Here are 3 things software developers can do to handle scope changes without coming across as a naysayer πŸ™Œ

1️⃣ Assume they don’t know what is easy/hard

For outsiders in any field it is very difficult to estimate effort it takes. E.g. I don’t know what things are easy/hard to do in an average biology lab πŸ€·β€β™‚οΈ

Software is the same for non-developers. So cut them some slack, and explain what parts are easy/hard to do. Most of the time that helps them to rephrase their request into something you can implement more easily.

2️⃣ Understand the problem and propose a different solution

In the XKCD example above try to understand why birds? Ask them about the confidence they need? Most of the time, having a thorough understanding of the problem allows you to come up with simple alternative solutions that will provide 80% of the value with 20% implementation effort

3️⃣ Explain your capacity

If you know the effort it takes to implement, don’t just add it to your backlog, instead show your capacity and backlog to them.

By looking at your capacity and backlog together you can visualize what you are currently working on and explain that, in order to do the new thing, you will need to remove something else. This is better then just saying β€œwe don’t have time” because it gives the other person the option to make a trade off and reprioritize, while still protecting your workload.

However, in my experience, most of the time the new request get dropped as the things in your backlog are more important πŸ˜‰

Image Credits: XKCD

Discussion (0)