It’s time to plan the next sprint for your engineering team. Your goal? Build the perfect sprint, complete as many features as possible — and do it while making sure everyone reaches the finish line on time.
You and the product team collect requirements from every stakeholder. You create the perfect specification to answer each requirement. But something is missing: you have no idea how long each task will take. So, you ask your developers how long it will take them to complete each task.
Congratulations, you have officially entered into a world of pain.
What Does It Mean To Estimate?
First, we need to understand what it means to ask developers to estimate how long it will take them to complete their work. You can’t speak to them as a collective, since they might have different opinions on the task at hand (pun intended). Or you might have a very large team.
Asking each developer directly means you’ve already decided who does what before you even considered any estimation, since different developers might suggest different timetables for the very same task!
This game of Tetris has even more constraints, though.
We take tasks — each with an arbitrarily attached time estimation — and then we try to assign each developer with as many features as possible until our sprint is fully booked. However, we still haven’t considered priorities. Holidays. Sick days. Unexpected bugs. Automatic tests. Necessary refactors. All of the unknown unknowns.
And that’s not all.
The estimation given for a certain task is, well, just that. An estimation — meaning it can be completely detached from reality. If a developer has a certain amount of features to complete in a sprint, and one is completely underestimated, then a planned feature might not be completed on time!
Since we know many things can (and will) go wrong with this process, we try to apply some buffer. Sometimes as days, other times as a percentage of the originally estimated time. Nothing promises us this buffer will be sufficient.
But something is missed here.
Feature Quality vs. Quantity
As an engineering leader, your job is not to do as many features as possible for a single sprint.
A significant part of your job is to complete as many features as possible, while ensuring high quality, during the timespan of your reign (which will hopefully be years).
There are plenty of important tasks to do that are unrelated to features: bugs, refactors, automatic tests, integrating with new tools, research, etc. If you have no room for dealing with technical debt in your sprint, then no one will get to it.
And when it comes to technical debt, you will pay with interest.
This game of estimation, more often than not, leads to another game: the blame game, where the unexpected happens and someone doesn’t finish a task on time. Instead of admitting that this system is flawed, an engineer who didn’t finish a task on time will have to provide explanations, which they will inevitably interpret as being blamed.
If the engineer is defensive, they will then blame the team leader, product manager, or simply the bad weather. This is no one’s fault. An estimation is merely an educated guess in the first place. We should not have built a house of cards on top of it!
A Different Approach
I’ve painted a bleak picture, but do not despair. There is hope.
Let me suggest a different solution to this common problem. Let’s reverse the question.
Instead of asking, “How long will it take you?”, let’s ask, “Can it be done in a sprint?”. If I ask you how long will it take you to build a chair, you might not know the answer. If I ask you, “Can you build it in a month?”, you will answer, “Most definitely!”.
Let’s assign a single feature for a single developer. This is their obligation for each sprint.
If one finishes their feature, they will then proceed to the rest of the tasks a developer should do. Fixing important bugs, writing automatic tests, refactoring painful areas, researching an important topic, integrating new productivity tools, or helping teammates.
This way, no significant technical debt is accumulated. Meaning we will actually do more productive work in the course of a year — rather than doing painful maintenance, manual testing, and daunting bug fixing in areas of code we should have just rewritten.
This is not all we gain from this approach. Lots of things just got extremely easier.
How do we estimate capacity? Easy!
The number of features a team can do in a sprint is equal to its number of developers. It’s now really easy for the Product team to break a big feature into milestones — each of them providing immediate value for customers — since the timespan of a sprint is intuitively gauged by everyone.
We also don’t need to do any manual work, like manual testing, since we always get the time to cover new code with automatic tests.
Nor do we need to dedicate developers for just bug fixing, or just test writing. Their happiness level is increased, since everyone gets to write a new feature each sprint!
At Axonius, we avoid this game of estimation. We take a more productive approach that leaves room to deal with technical debt sooner rather than later. We truly believe this way, we actually achieve a lot more in the course of a year, while keeping our developers happy and more productive. By simplifying the planning process, we make everyone’s life a lot easier, allowing them to dedicate more time to actual productive work.
Want to work alongside Nadav and see how his approach works in real life? Axonius is hiring! Check out the careers page to learn more and apply. 
