Τhe question is not “why things go wrong when I estimate effort?”, but rather “what can I do to make better estimations?” or, even more to the point, “what can I do to make sure that when I’m wrong, at least I’m not that wrong?”. Curious?
I think we can all agree that estimating effort in software development is hard. If you’re not convinced, feel free to checkour previous post about the challenges involved. So, the question is not “why things go wrong when I estimate effort?”, but rather “what can I do to make better estimations?” or, even more to the point, “what can I do to make sure that when I’m wrong, at least I’m not that wrong?” Curious? Read on to find out.
Although estimates involve some element of guessing, this doesn’t mean that you should make a blind guess. Estimates must be what we call educated guesses. It means that you first gather all the data relevant to the task at hand, and then take a best-effort guess given these data. As a practical example, let’s assume that you build a web application with a database at its backend. Your immediate intuition may indicate that changing some database fields might seem easy. If, however, you forget to migrate your existing database, you may end up in a so-called dirty state. And, considering that you also have to test in your staging database before moving to production, you may need to pump up these estimates.
In most (if not all) cases, nobody knows better how long it will take to complete a task from the person assigned to it. So, the next time you need to update a feature of your product, ask the person responsible for implementing this change. You will be surprised to find out how often your estimates may be completely wrong. A supposedly week-long task may turn out to be a few hours work, while a “simple change in the UI” may require two weeks. So, there is only one way to make good estimates: discuss them with your team and listen to them. After all, don’t forget that good team communication is one of the most critical factors for the success of any project.
Remember our previous post on effort estimation? Estimates can and will be wrong. So why not have a plan B? For example, if you want to ship your product at a specific date, you should prioritize all features and make sure to develop first the ones that have to be there. If all goes well, the rest of the features will also be implemented on time. If not, well, probably your initial estimates were off, but now you at least have a product. Speaking of prioritization, this is the agile way of doing things; building the product one feature (or one sprint) at a time and trying to deliver value early on.
Whatever you do, never ask for an estimate and treat it like a deadline! Doing so is unfair to the people involved in the task, and can often result in overestimation on the part of your team or, even worse, low team morale. Remember what we’ve agreed on so far: estimates can be tricky business, and making them just right is far from trivial. I’m not saying to overdo it and leave everyone to set their estimates without restriction. Let’s not forget Parkinson's law, according to which “work expands so as to fill the time available for its completion”. Instead, it would be best if you discussed with your team and set both the deadlines and the estimates in the same meeting room.
For example, you can first decide when to ship the next version of your product and determine which features you can (and should) include. By estimating the effort for those features, everyone will be able to see how much work is expected per development sprint. After that, while working on delivering features, you can go back to your estimates and check whether the original plan is reasonable given your team’s throughput. If not, you don't need to correct any deviations by reducing the overall load or by trying to increase an already maxed outperformance.
Everybody has their expertise, so moving tasks among people is not that simple. If one of your rockstar front-end developers expects a task should take no more than a day, this does not mean that all developers in your team can do it in the same amount of time. And most of the time, they shouldn't; you wouldn’t want your database engineers to put double the effort for a task not suited for them.
As a side note, always keep an eye on situations where your team members disagree on estimating a task. If John says that a task requires three days and Mary insists that it should take seven, the only safe and sane way is to talk about it (“Mary, please tell us what makes you think that this task requires seven days”). Assuming that John can do it faster and assigning the task to him may seem effective. Be careful, though! What if you are walking on thin ice? What if he didn't consider a crucial detail that Mary did?
Last but by no means least, remember that it takes time to develop high-quality software. If you focus on delivering your product fast without taking into account non-functional aspects, then it will come back and bite you. Stretching your sprint to fit yet another feature is never a good option unless you want to spend the upcoming month doing a massive refactoring in your codebase. Check your estimates so that they include time to design, develop and test each feature. Only then you can safely claim to have shipped a successful software product.
There it is; these are some of the rules we try to follow when estimating the next sprint. What do you think about them? Did we forget something? Choose the medium of your choice, Facebook, Twitter or LinkedIn and reach out to let us know your tips for estimating effort!
Till next time folks!