The Dev World – Sergio Lema

Estimating tasks is one of those things that looks simple on the surface, but quickly turns into a developer’s worst nightmare. On one side, I’ve got the product owner breathing down your neck, desperately needing to know when that shiny new feature is going live, while on the other the QA team wants to figure out when they can start breaking it (because let’s face it, they will).

But one thing’s clear: the need for some form of estimation isn’t going away anytime soon, especially with the product owner trying to align timelines, customer expectations, and release cycles.

The typical developer team doesn’t make this any easier. You’ve got the senior engineers, who’ve been around the block enough times to know that estimates are just guesses in fancier clothes, the mid-level devs still optimistic enough to think their estimates will hold up, and the junior devs who don’t yet know what’s about to hit them.

Everyone’s got their own approach, and somewhere in this mix is supposed to be a unified method for predicting how long a task will take. Good luck with that.

Estimation in Time

Estimating tasks in time provides a straightforward metric that the product owner can easily use to plan releases, set deadlines, and communicate with stakeholders.

Having clear time-based estimates helps align the development process with business objectives, making it easier to manage expectations and resources.

However, this approach comes with its own challenges.

Junior developer may estimate a task in two days, while Senior developers can do it in two hours. So, let the Senior developer do the task. It doesn’t work this way.

So, let the Junior developer do the easier tasks and the Senior developer do the hardest tasks. But as I use estimation in time, the complexity is not proportional to the time.

And what if the Senior developer is busy with a task, so the task is redirected to the Junior? Do I need to multiply the estimation time by 2 or 5? I need to estimate the task again.

And when we are in a Sprint planning, how do we estimate the tasks? For the Junior or for the Senior? Or for an average developer?

It’s not easy to decide all this. What’s easy is that the sum of all the tasks gives the amount of work time.

Estimation in Points

Estimating tasks with complexity points shifts the focus away from time and instead looks at the difficulty or effort involved in completing a task.

To estimate tasks using complexity points, the team must first define what’s a complexity point. Generally, we use a logarithmic scale, 1, 2, 4, 8, 16. We choose the middle point, 4, and define a regular task for it (like creating a CRUD operation with its endpoint and a new column in the database). From there, I can say: it’s easier that the reference task; or it’s a lot easier; or it’s harder or a lot harder.

One of the main advantages of this approach is that the estimates remain consistent, regardless of who takes on the task. Since complexity points reflect the inherent challenge of the task, they don’t change when the work is handed off to another team member, whether they’re a Senior developer or a Junior.

It also helps developers think about the work in terms of effort rather than time, which can often be a more realistic way to approach unknowns or difficult tasks.

However, using complexity points also has its drawbacks.

The product owner, who is often focused on timelines, may struggle with this abstract measure. Without a direct conversion from points to hours or days, there’s a temptation to simply add up all the points and try to cram as many tasks as possible into a sprint, which defeats the purpose of this approach.

Complexity points are designed to give a more nuanced view of effort, but without clear guidance on what they translate to in terms of time, it can be difficult for non-technical stakeholders to make accurate sprint plans.

The best solution for that, is wait some Sprints until we see a clear constant of complexity points which were consumed. As the team is always the same, it can handle always the same amount of complexity tasks. The Junior can do 3 tasks of complexity 2, while the Senior can do 4 tasks of complexity 4. This sums up to 22 points into a Sprint.

Conclusion

When it comes to estimating tasks, both time-based and complexity points have their pros and cons. Estimating in time gives the product owner a concrete number to work with, but the accuracy can vary wildly depending on who’s doing the estimating. On the other side, complexity points offer more consistency across the team, but can leave the product owner scratching their head, trying to turn abstract numbers into real-world deadlines.

In the end, it’s about finding the balance that works for your team and making sure everyone’s on the same page—even if that page sometimes feels like it’s written in a language no one quite understands.

But hey, whether you’re estimating in hours or points, just remember: estimates are like pizza delivery—no matter how confident you are, there’s always a chance it’ll arrive later than you promised!