Prologue

Nobody like estimates or estimations in general. They are often vague, erroneous or needed in such a short time, that we do not have the luxury of investigating and properly assess our work before having to come up with a magical number to solve our problems.

But the trick with any sort of magic is the fact that is it usually comes with a price.. a hefty one too.
In Act 1 we will see some cautionary tales of when the estimations start to smell bad from various reasons. Should you find yourselves in any of the situations described in Act 1, please hit the pause button and re-evaluate your decisions as they should be treated as red flags when doing estimations.

Act 2 is more cheerful and focused on better practices and how to tackle some of the common issues encountered while coming up with estimations.

Act 3 is dedicated to those who are in a spot where they know they need to do something, but might not know where to start. Or to those who want to try out something new to up their estimation game.

Actors

• Companies working with Umbraco and estimating tasks
• Exasperated project managers/ Scrum Masters
• Developers that gave up a long time ago and are relying on their experience
• A young hopeful junior

Act 1 - Stop setting up for failure

Should you find any of these situations familiar, please raise a flag and you will be escorted out of your lodge and taken to visit a medic momentarily.

Someone is estimating the tasks for you

This one might be one of the most obvious things that can happen. A developer that will not work on the project, or even worse, an ambitious project manager starts estimating the tasks in the sprint backlog. The people involved in the project should be the ones estimating the tasks- they are the ones who should have the most context and need to gain an overview of the project as well as take ownership of the tasks and estimations.

Not having buffer time

If, while working on your task, you will find yourself putting the last semicolon in the very last minute of the implementation, and you can't catch a breath before you have to pick up another story from the board, you are missing buffer time. Running from task to task creates a suite of other issues at a personal level like burnout, stress, but also at a professional level through encouraging the birth of technical debt. Sometimes, you hit a wall with a specific task and if there is no available time to finish, corners will be cut, people will be rushed, project managers will be upset and the project is risking delays.

Estimating something you have not done before

You cannot accurately tell how long a task will take if you have done nothing like it previously. This is less of an issue for an experienced developer who has some projects under their belt but for a fresh-out-of-school junior, the situation can be daunting. Luckily, in most cases, you or one of your colleagues will have the experience to make the estimate. However, be wary, not too fall into the trap of letting others make the estimation for you. Instead, you could ask for a investigation task and talk to your colleague to get some context and share some knowledge before accepting to take on the task and providing an estimate for it.

Giving only one estimate

Few clients will ever be able to understand the more technical aspects of your tasks; therefore, as developers, we try to paint a picture of how complex a particular story is and try to make it universally understandable by assigning a number to it. Numbers are easily understood by anyone and for the most time are easily translated into currency by the client. The danger with reducing a piece of business logic to a single number is the fact that because people can understand that number, they will take it at face value. But this means that you are now restricting yourself to an estimate. What if something goes wrong? What if the task is more complex than initially thought? What if the client expected the functionality to include translations into Swedish as well? We are now stuck with a fixed scenario. Next time when faced with a situation such as this one, try to answer a question: do I have enough confidence in this number to tattoo it on me? If the answer is no, then perhaps you need to re-estimate the task.

"We did this much last sprint, so we do more this sprint"

Not True. It's good to be ambitious but we also should consider realistically, how much can you actually achieve in this sprint? aiming higher is a good idea but can become a slippery slope that can affect team morale. Also, in situations like these, if you keep on missing your sprint goals, your team might actually start to have less and less faith in themselves and in that case, a botched estimate is the least of your concerns.

Most of my tasks take at least several days

Hmm... this might work for some but it might be a major red flag in most cases- in general, the bigger the task,the harder it is to control and evaluate. If most of your tasks take a high amount of hours, maybe it's time to reevaluate how granular you are making your tasks. Besides, this generates a whole new suite of issues like higher risk of missing the scope or trying to implement too much at once.

Act 2 - Experiment with a new approach

If your estimates are suffering a lot right now, you might want to try a new way of doing things that could make more sense to you.

Give 3 estimates per task

Instead of delivering a single number and tying yourself up with it, give three possible estimates. The "everything will go perfectly" one, the "everything that could've possibly break, will break" one and the "alright, really now, how long will it take" number. This way, you can mitigate some of the possible damages by showing the client that you are prepared to meet the deadline, even if you tumble upon some unexpected challenges along the way. Might want to avoid making the realistic number an average of the best and worst case scenario as that can also land you in a sore spot. Rather, try to evaluate each scenario individually.

How long will this task take without...?

Most of the estimation issues arise from the unanticipated (or insufficiently anticipated) task-related incidents. There is a tendency to hone in on the task at hand and focus on delivering an estimate. But does that estimate include QA? What about a return from QA with a bug? How about PM hours? Client communication and clarification on the task? What about integrating that task into the already existing code base? The pull request writing? Git flow? Deployment? The list can go on and on. So why don't we factor in all these things? Cutting corners usually makes things worse- and the idea of estimation is not to fit or deliver number but to find a realistic flow that will lead to a realistic number.

Tell the Project Manager/Scrum Master

If you think you will miss the estimate, talk to the PL by all means. They are there to figure it out and do you really want to open friendly fire on the only person standing between you and an angry client? Build a relation with the PM based on positives and trust.

Try a more structured approach

If you are using a less structured approach with this, try to introduce some structure in the approach. Are you estimating freely in hours? Try using Planning Poker cards and open up the discussion around the numbers on the cards for everyone. It might simply be that one of the developers gets to estimate most of the project and the others just fall in line but don't manage to pick up the pace.

(Just in case there are people out there over-engineering this) Are you estimating in hours and having a hard time keeping track? Try T-shirt sizes (XS, S, you get it) instead. Might give you a bit more freedom and make estimation meetings go faster.

Stand your ground and say no

In some cases, we are put in difficult situations as devs: having to estimate without a complete list of specifications, or based solely on the wire frames from design, or none of the people who actually knew what the client wanted were available, or we are politely informed that the project has been estimated by someone else and we have to somehow make it fit. Sound familiar? There are situations when we simply have to put our foot down and actually say "No" and stand up for ourselves. Because if we start estimating with insufficient information, that will result in a bad experience for the client and PM, stress for you and most likely the other people involved in the project. So sometimes, it's a good idea to simply stand up and voice your concerns. If not, your silence is considered a silent agreement. Be polite but pragmatic and express the situation as best you can and the consequences.

 

Act 3 - A New Hope or Things you can start doing today to get better results

Account for some intermezzos

Once you get into a state of flow, it's hard to get out. Sometimes we forget to about ourselves when we are focused, and we tend to go at full speed, ignoring some of our basic needs. "I'm just going to fix this bit and then I'll stop" - sound familiar? Why is this important? Simple: This is the best way to maintain yourself not just for your own sake, but your teams' and  projects' sake as well by avoiding burnouts and stress. 

You can use different techniques to implement a time tracking system that will allow you to take breaks - you can use Pomodoro, for example, where you work in focused sprints of 25 minutes and then have a 5 minute break. Every 4 sprints, you take a longer break (15 or 20 minutes). This may sound a bit forced in some respects and a bit unethical in others. However, we are not machines, we need breaks, coffee, food.

Do you actually work 8 hours every day without interruption or do you get up to grab a cup of coffee, send an email with clarification or just ask your colleague a question? Then adjust your estimates to reflect your work day... as a human. 

Get a baseline story

Find the simplest story of every sprint and use it as a benchmark when estimating in story points. It should usually be the 1 story point task but it could also be higher. It is important that the task is the simplest one of the sprint and that you estimate in story points. This makes it easier to estimate the other tasks by comparison, keeping the 1 story point task in mind. 

Get a little tool for estimating

How many times have you forgotten to account for testing or PM hours on a task? what about your colleagues? If I think you can do the task (just the task, stripped of everything else), you can start adding different percentages from that task for project management, QA, client communication. And remember to have an optimistic, pessimistic and a realistic scenario for each one. This way, you can ensure, you have all your bases covered for accounting for all the connected events of that task, not just a task as a single, isolated unit.

Continuously evaluate /re-estimate

After spending 50% of the time on the task think: am I 50 % done with it? Do I need to contact the client for more time? Where did it go haywire ? How do we manage it with the project manager?

Integration tests

This is probably an insignificant part at the beginning of the project and has a steady growth in importance as the project develops. As the project progresses, more and more time should be allotted to the integrations of the task with rest of the system. This prevents introducing a new bug along with a new feature. By the end of the project, as much as 80% of the task should be the integration testing and QA.

Epilogue

Last but not least, some projects are born under the guidance of a failing star and the estimates will fail spectacularly, regardless of how well you handle it. It is never a pleasant experience; it can however, be turned into a valuable lesson. 

Every project has something to teach us. Probably the most common cure for any estimation related illnesses is experience- so embrace every project, good or not good, try some of the above mentioned techniques and it will help you up your game.

Special mentions to Poornima, Jesper, Leon and Jan for sharing some of their highs and lows for this article.