A lot of teams struggle with story or task estimates. And I see teams choose to forgo estimates when they find them challenging and don't see value in them. But there's a ton of value in these kinds of estimates! And it's not just committing to deadlines 🙂
Estimating takes practice
One of the primary reasons I see a team skip estimating is because "no one is good at estimates." The team thinks that if the estimates are always wrong, why estimate at all? This is flawed reasoning because estimating is a skill like anything else. With practice, everyone can get better at estimating.
But this also assumes that we want estimates to be correct and accurate predictions of how long something will take. While in a perfect world, that would be wonderful, that's not where an estimate is valuable.
Estimates are valuable in their relative size. As a team practices estimating, they get really good at being able to tell which stories or tasks are bigger than others. And roughly by how much. This makes planning a sustainable workload a lot easier.
With team estimates, we don't assign the same number of tickets every sprint without knowing their size. The team can commit to about the same workload week over week, regardless of how many tickets it is. Some weeks it could be 7 and others it could be 13.
Being able to see how much work the team has planned helps us manage non-delivery time. Things like time off or other team priorities such as hiring activities, on-call rotations, or team building. A sustainable workload is one of the primary ways to prevent burnout and turnover.
Another reason teams skip estimating is because estimates have been used punitively in the past. If a team was punished when they didn't meet an estimate, then it makes perfect sense why they no longer do them. When this occurs, it points to a much larger top-down culture problem within the organization.
Estimates are educated guesses to set realistic expectations. Estimates are not predictions or promises.
Fear and shame-based motivation are extrinsic motivators. They have a short shelf-life. They also do a lot of damage to your team's mental and emotional health.
Punishing a team that exceeds its estimates won't lead to better outcomes. A team needs to feel psychologically safe to explore and innovate.
When estimates are punitive, leadership needs to step back and reevaluate how they're using them. Often, this is where my coworkers and I step in. External consultants are uniquely poised to have hard conversations. We educate higher-ups on how to use the information estimates provide and reset their expectations.
We need to treat estimates as communication tools rather than hard deadlines. This creates a safe space for teams to creatively problem solve.
Finally, I see a lot of teams missing the value of estimates as a way of knowing when to ask for help.
In team cultures that celebrate "rockstar programmers", using estimates in this way is scary. An individualistic team culture discourages (or at best tolerates) asking for help. In a collaborative culture, estimates act as a guidepost to let a team member know they might be rabbit holing and should ask for help.
Creating estimates as a team means agreeing on the amount of effort a task should take. This shares responsibility when something takes longer than expected.
If a team member gets stuck on a 1-point story, they have a shared expectation of how much individual troubleshooting they should do. If your team treats a 1-point story as roughly 1 day of work, the assignee can reach out for help after a few hours if they haven't made progress.
Changing team culture is a slow process. But estimating as a team is one strategy to start building a collaborative culture.
Team estimates are valuable software development tools. They help teams plan sustainable workloads, create space for problem-solving, and provide guidance for asking for help. Teams shouldn't abandon estimating because it's hard. There's tremendous value in estimates, and with a little practice, we can all get better.