There’s a plethora of articles, books, and blogs on how to accurately estimate large software projects. Something that’s going to take multiple developers a decent chunk of a week, month, or year will almost always have meetings between developers, project managers, and other staff where estimates will be checked and challenged.
Where I have definitely struggled to improve, though, has been estimating the all-too-common ‘small’ tickets: ones that are large enough that an estimate is expected but too small to necessitate bringing in additional help or conferring with other developers.
For me these are tickets typically are somewhere in the 4-15 hour range. Anything less is likely a simple enough solution to go on gut instinct, and anything more might affect my schedule for the week, so I’d likely need to run it by someone else.
Here are some tips and tricks I’ve found help me independently estimate this type of task.
Compare to Completed Tickets
This one is a bit obvious, but if you can compare the current task to a completed task, you can get a really great baseline with which to work. For example, if a client is looking to mimic the analysis of another report but reference a new set of data, seeing how many hours were put into the ticket regarding the original report feature can help give you a ballpark.
This also speaks to the importance of labeling and linking tickets and issues. Institutional knowledge of a project and specific tickets are great for experienced developers but without some sort of trail or documentation of past work, newer developers will have a hard time knowing that previous efforts might be applicable to new problems. While it can feel tedious, be sure to fully learn and utilize all the various tools of your ticketing or project management system.
Think Work Days, not Hours
Sometimes trying to assign specific hours to a task can be daunting. Will figuring out this specific loop I know I’ll need take an hour? Three? Maybe three and a half? Estimating specific elements of a ticket can start feeling especially nebulous and arbitrary, which can easily lead to spinning your wheels while estimating.
When I find myself in that situation I’ll often ask myself the following question:
If I was given an entire work day, am I confident I could get this task done?
This question can help set the boundaries for tickets. If your answer is a quick and resounding ‘yes’ then you know the estimate can be narrowed down to somewhere in the 2-8 hour range. If your answer is a resounding ‘no’ then it’s likely time to talk with a project manager or at least take some time to figure out why exactly this will be a multi-day task.
If your answer is a less solid ‘yes’ or a ‘maybe’, some other considerations should come into play. Context switching is likely to become an issue in these instances as urgent bugs and meetings are extremely likely to interrupt your work in this type of ticket. When I am estimating a ticket with a ‘maybe’ on completion in a single workday, I tend to add about 10-20% more time on whatever my final estimate is purely for context switching. That way stepping away from a ticket does not have any additional pressure to try and make up for the time from context switching.
Rubber Ducky Your Pseudo Code
This is a way I double-check my level of confidence in an estimate. If I can write down my pseudo code and then talk my way through how that pseudo code will complete the requirements, I can feel confident that my estimate will be accurate. If I have trouble talking out the whole process or feel shaky about where exactly certain parts of the solution would fit, then I know I should add some padding to my estimate.
I recently had an example where this method led me to more accurately estimate a ticket. I initially estimated a ticket taking four hours based on previous similar tickets but I decided to step back and actually write out some pseudo code for the solution. As I walked through the process in my head, I floundered a bit on whether a particular part of the planned code should live in a controller or the model. I bumped the estimate on the ticket to five hours because of my hesitation and the final tally of time spent on the issue was four hours and forty seven minutes.
Retrospectives
Whenever I go ten percent or more over my estimate on a ticket, I try to take some time and figure out why I underestimated it. Was it a communication issue? Did I not fully understand the requirements? Did I forget to include time for writing tests? Was context switching or catching up on project changes an issue? Maybe I just plain old thought one specific method would not be as complex as expected.
Estimating is a skill and skills take time, effort, and experience to improve. Taking time and really digging into the specific causes of an inaccurate estimate can sharpen your estimating skills dramatically.
Gut Instinct and Willingness to Fail
In the end, your gut instinct is often one of the most important parts of estimating tickets. Sometimes a feature is entirely new and does not have a relatable, completed ticket. Maybe it will require interacting with a newer framework, so you are unsure if something will take a day or a week! Those kind of situations can be especially nerve-wracking as estimating those can feel like exposing yourself to a situation where you will be way off base. The reality is that you likely will be from time to time. Remember that learning from mistakes is always one of the best ways to improve at something!
All the Pieces Matter
Estimating small tickets may not seem to be as essential or dramatic as estimating large projects, but consistently giving more accurate estimates for large numbers of small tickets can be a major boon for both developers and clients. Being half an hour to an hour more accurate on small tickets can quickly add up to significant numbers.
It gives clients more confidence in what they can tell their stakeholders to expect and it allows for better forecasting and resourcing for developers.
Tags: