We all estimate at work. It's part of our jobs and we shouldn't run away from it, be afraid of it or think it's unimportant. On the contrary, estimations help us guide the project to success from the point of view of both clients and developers. They are all we can know about the future and, with some limitations, they make it possible for us to make important decisions when it matters the most.
Being aware of how much an implementation might take time gives us the required information to see further than the work right in front of us and helps the team strategize ways to incorporate the bigger picture.
Don't think estimating is a synonym for guessing. It is if you haven't done your homework, and these chapters will give you the necessary tools and techniques to be able to do the homework.
Receiving an estimation request
When will you be done with this?
It's natural to feel a bit challenged when asked this question, because it makes you feel responsible for achieving a desired goal in a certain time span. There are cases when the amount of work is too large to provide an optimistic estimation; however, don't just ask "why", because that might also trigger the requester to give you an answer that doesn't help you in any way:
Because I need it!
"Why" questions tend to trigger defensiveness, as they’re easily misunderstood as questioning the actions of another person. Instead, rephrase your "why" questions as "what" questions. Those generally receive a more specific answer:
- What decision depends on this estimate?
- What will happen if we don’t meet the deadline?
- What isn't a part of the MVP if we need to meet a deadline?
With "what" you can frame the question to give you the responses you seek. Sometimes the conversation might lead you to safer waters, giving you more time to analyse the request, get informed on the business domain or avoid estimating altogether.
Demystifying the request
It's highly likely you'll need more information on what the goal of the proposal is. The implementation details can come later, but you’ll need to get a feel for what’s intended.
Thinking and talking with the originator of the idea will bring you closer and more in tune with the desired request, making you feel more assured once you need to put down a number. You might have a project with multiple owners or clients and talking with everyone will result in a joined mental image of the desired outcome. Expect to backtrack along the same path as the request gets clearer and more questions pop up. In order to minimize this process, be transparent and leave a written trail which everyone in the team can see. Usually, Slack channels, Productive or Jira tasks, and Confluence documentation pages are the way to go. Avoid direct messages!
Be aware that some delays can occur during this phase. The client might be slow in collaborating, they might not know the answer to your questions, or they aren't in a position to bring decisions. Don't stress if this happens. Your PM is responsible for pinning down the client and extracting any information that might be blocking you to do your work. Let your TL know too in case you are left empty handed.
Accuracy and Precision
After collecting all the answers you need and using some of the techniques described in subsequent chapters, think about the accuracy and precision of your estimate. By trying to be overly precise, you may make an estimate unnecessarily inaccurate. Remember that you are creating estimates, not measurements. Ask yourself:
- How confident am I about the estimate?
- Would an additional day make me more optimistic?
- Have I ever built such a feature?
In the end, it's best to provide a number of hours and express your optimism in percentages:
To implement this feature I think we'll need 8 hours, but I'm 60% confident about it. If it's ok to increase it to 12 hours, I'm almost 90% assured we'll make it in time.
You generally want to create estimates that keep you outside of the danger zone — plus a little safety margin for error. Usually, that margin is around 50%.
If you can think of a potential cost, put it in the estimate. Document the assumptions of it, and as long as those stated assumptions are valid, you're in for a nice ride. Otherwise, if your assumptions remain implied, it may happen that they turn out to be false and you may find yourself in a problematic situation if the contract cannot be renegotiated.