My Approach to #NoEstimates

For the two and a half years, I’ve been running projects with significantly less estimation ceremony. The approach has not been perfect, nor has it been entirely without estimation of any kind. Here’s an overview on how I tried to make it work.

Backlog Setup

At the beginning of each project, I met with Product Owners repeatedly, for deep dive conversations about what they wanted out of the project. My starting goal was to identify the least amount of work possible to barely satisfy the project needs. This would be our starting point and represent a complete (though probably sub-optimal) workflow. I’d reasure the PO’s that this doesn’t stop us from getting the gold plating, it just ensures that the core capability exists first.

The goal of this effort was to have a list of sentences in user story format. The totality of these sentences should represent the least possible amount of work to meet the user needs. Each line should represent work that appears as small as possible while still being valuable to a user and negotiable. Mostly I try to get them to a size that feels like 5 days is more than enough to get from start to completely done.

Backlog Growth

The cycle above repeats, usually with a fair amount of frequency, adding missed needs, high value gold plating, or glue features that connect this value to other workflows. The goal is the same: a deep understanding of what is crucial, and sentences in user story format that feel small. The important discipline to add to this is making sure that this expensive level of definition doesn’t happen too early. Nobody benefits from a huge backlog.

Often, Product Owners will want to add stories without this deep conversation. I separate these stories from the working backlog until we’ve met and processed them.

Prioritization and Forecasting

I work with Product Ownership regularly to review prioritization. We start with some arbitrary straw man – usually the order I wrote them down in, or their first thought on priority.

Once we have an initial priority, I can provide some forecasting. I represent this by placing a “Green Line” and a “Red Line”. The “Green Line” indicates where I am confident we can get to by the desired deadline. The “Red Line” is the least number of stories I think we won’t get to. Everything in between is the “Yellow Zone”; stories we might do in time. With this framework in place, we have a tool to ask powerful priority questions.

How do I draw the lines? It doesn’t matter. You can come up with lots of ideas. The important thing is that once they are drawn, you have a framework for transparency, realism, and negotiation.

Negotiation

When Product Owners want to change the order of the stories, do it. When they want to add a new story, process it, and make it the next thing on the backlog, do it. If they want to re-slice stories, do it. Don’t let them drastically change a story that is already in work. Don’t let them re-arrange priorities with work that is already in progress.

This part is harder than I thought. It was my goal to have this type of flexibility, and sometimes made me uncomfortable. For some people on the team, it was even more uncomfortable. The idea that we’d be in the last sprint of a release and still changing scope (albeit at very small scale) really bothered some people.

Summary

There are about a thousand other details for me to talk about here. I’ll probably have follow up posts on story sizing and dealing with Product Ownership questions.