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
Top comments (0)