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 🙌
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.
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
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