Beyond Time Estimation

1. Introduction

Developers are rife with stories about late projects. Management’s unreasonable expectations combine with developers’ struggles to code vague requirements. Despite these challenges, there are tangible benefits. The primary question is, what are we getting out of time estimation in development?

2. Time Estimation On Hard Mode

How long is a task?

It’s very difficult to estimate individual developer tasks, stories, and project timelines. A natural gap exists between the promise of a feature and the delivery. This gap causes the feeling of “hard mode” for the development team. As my career progresses, my delivery speed has improved resulting in this mode being reduced.

What is the goal?

The goal of estimating is to better manage expectations. Software developers must show continual progress in the software’s development. Still, there is major difficulty in time estimation for developers. Missed hard deadlines can cause distance between business and development. What are some ways we can remove this difficulty, beyond “being a better developer”?

3. Problems With Task Estimation

Beyond Our Control

The factors we cannot control can be the most discouraging. A task that is repetitive and routine, not complex, and standardized would be easy to estimate. If we added a lot of historical data to this repetitive task, we could estimate how long it will take. Unfortunately, these tasks resemble an old car assembly line. Software development tasks are not repetitive and routine.

The Ideal Task

Stories dependent on each other will slow down development. These dependent stories make for a waterfall process. The goal is fitting independent stories. We want small pull requests that are easy to review and merge. Independent scoped work enables parallelized tasks. To succeed, make sure the ask is well-defined.

Complicating Factors

If what we are working on is complex and novel, that is going to bring many challenges. Novel or innovative tasks make development even more challenging. There is often a creative element to development. Finding ways to reduce complexity is not simple. Keep it novel, but avoid the complexity.

Scope, Uncertainty, And Shifting Priorities

Finally, we should cut project risk or uncertainty. A typical mitigation strategy would be to use familiar tech while avoiding new tech. We have to avoid tasks that shift in their goals or lack the clarity needed. These tasks increase the likelihood of unnecessary rework.

Collaboration As A Risk Factor

Collaborating with others is a time sync. The more collaboration required, the more likely we are to miss deadlines. External parties introduce even more difficulty in collaboration. External customer meetings are necessary throughout the project. It’s common for projects to need high coordination. There is no replacement for good working relationships.

4. Benefits of Task Estimation

Encourages Team Collaboration and Shared Understanding

Estimating has led to product discussions with developers about scope and requirements. Acceptance testing is another method to create these discussions. Estimation may be a welcome side effect while developing a shared understanding.

Identifies Risks and Unknowns Early

Identifying risks upfront or as early as possible is important. Funny enough, XP and Scrum somewhat disagree on requirements gathering. XP believes requirements are more incremental. Scrum believes a large part of tasks is estimable. From what I’ve seen, the latter is a bit of a pipe dream. Still, the truth lies between these two statements.

Manage Scope To Build Trust

Scope in general is something I’ve been thinking about more lately. How do we identify all parts of this epic, story, or ticket, so we don’t end up in the trap of ever-expanding scope creep? I’ve been the guy who picked up “one task” from the backlog. It turned out to be a change needed in multiple codebases. I’ve seen overruns in general features countless times as well. The cause is not believing the engineers’ honest estimates.

5. Conclusion

As a previous business analyst, I find the most value in discussions about metrics. Time estimates result in similar discussions. The answer is to learn with the business how to develop the feature. So use task tracking as an aide for development.