Estimation isn't for everyone

Agile is good, except when teams forget the first rule of Agile: "Individuals and interactions over processes and tools". This article is a good reminder of that.

always talking about how we described the work, rather than the actual work itself.

if we just put the time and effort we were spending on estimates into actually completing tasks, we would get a lot more done

our role is to point engineers toward more of the work that matters and less of the work that doesn’t.

Estimation has its purpose, but spending so much time on the estimation process may not be as necessary, particularly when the team has been working well together and has demonstrated their ability to break work down.

I needed to forecast a completion window for our stakeholders. The problem was, without knowing the estimate for each ticket, I had very little way of projecting a date without committing the team to an arbitrary deadline.

Many developers have been breaking down work and iterating for their entire careers. If your team has been working together for a while, they should be used to cracking chunks of their problem space into manageable tickets. And once that problem has been solved, a few key metrics can track and even predict how quickly that work is finished.

I started to look at past performance data. [...] I looked at all of the stories that crossed the finish line in the six weeks prior, and saw that the average ticket was 4 points. That’s an abomination in a Fibonacci system, I know, but the numbers don’t lie, so I went with it. I put a 4 on every ticket in the Epic, added 20% for good measure, projected a date, and handed it over. We delivered within one week of my projection. And it wasn’t a fluke. We continued to shape our projects that way, and delivered consistently.

Velocity doesn't need measured in points. Number of tickets can work too.

Velocity is still the single most important metric to your team. Traditionally, that’s tracked in terms of story points, but it doesn’t have to be. Velocity is simply a measure of throughput, so why not leverage your issue tracking system and track the number of work items you complete each week? If your team finishes six tickets per week, and they’re breaking down tickets well, that’s your velocity right there.

Once you remove points from the process, you can use cycle time to check if the team is continuing to break down work appropriately.

If you’re worried that your team isn’t reducing its stories well enough, just turn to a concept from the Kanban method of Agile: Cycle Time. Track the time your stories spend between In progress and Done and you can tell how well you’re breaking down tickets. If the average cycle time of a task increases from, say, 36 hours to 7 or 10 days, use that as a catalyst for a conversation about work breakdown in those all important team retrospectives.