We've all been asked at some point by a team member or our manager, "Hey how long is this work going to take, can you give an estimate on it?".

Scoping is hard and not always as intuitive as one might think. Below are some ideas for scoping in a safe and practical way.

Fully understand the work AND the impact it could have.

When scoping, it's important to consider applications outside of the ones being modified. If you're updating the contract of a return payload for a service, does that break other services using it? Is there a data store needing to be modified to support this new value as well? Adding something to the contract might not seem so easy now.

Ask as many questions as you can up front to get a clear picture. Dig into the code, does it seem clean enough to get in there and make the change easily? Make sure you understand the ins and outs of the system being modified before putting a number on it.

Don't be Optimistic

I think Fred Brooks summed it up best in his book, The Mythical Man Month, All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy god-mothers.

Optimism can be dangerous, we might start out thinking that the work in front of us is a piece of cake, only to be humbled later by unforeseen consequences.

Just making the change

It's important to understand how to strike a balance between optimism and realism. As a rule, some amount of padding should be built into the scope. It's difficult to pin down how much extra will be needed needed, but depending on the complexity of the change I like to double whatever I initially came up with and then shave off some amount of time appropriate to the change.

It's better to over scope and delivery early than to under scope and deliver late.

Consider Process

Take for example, enterprise development. Things can be siloed and segmented to a point where even talking to someone on another team might require a meeting (I sincerely hope it's not like that for you, dear reader).

When you find out you need several meeting to talk to team members

If the change is reliant on a modification to a data store, do you have to have someone make that change on your behalf? What does their schedule look like for being able to get that work done?

Time can get chipped away in places you might not expect. So it's worth considering if you know there's going to be some process to follow ahead of you.

In the end, scoping, no matter how you slice it, can be tricky. There's almost never a magic number and it's probably never going to be pinpoint accurate. But we can scope safely and save ourselves some headache by thinking around the problem and being pragmatic in our estimate.