Agile Software Delivery with #NoEstimates

How can you make decisions about software development – in the presence of uncertainty – without estimates? Ask Nordstrom’s Innovation Lab.

[featured-image single_newwindow=”false”]A story map with a timebox enabled great things at Nordstrom.[/featured-image]

A small team of developers and UX designers converged on the shopping floor of the flagship Nordstroms to create an iPad application that helps people decide which pair of sunglasses they like best.

They were given one week (timebox) and continual access to their customers (collaboration) to develop their app. They started by creating a story map with capabilities, features, and stories. Once the stories were prioritized, they got to work.

By the end of the 1 week experiment, the team delivered an application that met the needs of their customers. And they did all of this without estimates.

So how did Nordstom’s Innovation Lab get a product shipped in 1 week without using estimates?

Here are a few key points:

1. Timeboxing:  By limiting their time to a week, the team had to slice stories down to a size that made sense within their timebox. This kept the work small and the stories focused. In other words, the timebox helped create a natural heuristic for breaking down work. This short timeline also helped to naturally limit the teams Work in Process (WIP).
2. Located the Team in the Store:  By putting the flash mob dev team in the middle of a store, the customer was always front and center in the process. The customers could at any time see what the team was working on and could provide much valued guidance and feedback as needed. This made sure that the team was “never working on anything not valued by the customer”.
3. Utilized a User Story Map:  The user story map kept the big picture in mind and also made the work visible. By breaking down capabilities in to features and features in to stories, the customer could then prioritize the stories and make sure that the most important items made it in to the app.
4. Paper Prototyping:  Cheap and quick feedback reduced waste and significantly lowered the cost of change. UX/UI ideas were quickly validated and refined by the customer in real-time (thanks to colocation) and only after the customer agreed was any code written. The design was emergent.
5. Short Feedback Loops:  The customer was involved in every decision and saw progress regularly. Trust was high between the dev team and customers thanks to these short feedback loops. This happened because the work was transparent and progress was obvious.

• What about forecasting Estimates at Completion (EAC)? You can’t do that with #NoEstimates!
  • What this is asking for is the forecasted cost at completion. And I think we can get there with the way that the Nordstrom Innovation Lab does their work.
    • The cost is fixed. Let’s pretend that it costs $10,000 per week to fund the team.
    • Let’s also pretend that the team finishes 10 stories per week.
    • Since the team created a story map (such a great tool – read Jeff Patton’s book to learn more) we can forecast how many weeks (sprints) it will take to complete all of the needed capabilities.
    • Multiply that number by $10,000 (weekly burn rate) and you can provide an EAC.
    • Is it perfect? Nope. Is it exact? Nope. Will it change? Yep. But it is likely accurate enough for some contexts.
    • And it gets more accurate as the project progresses.
• But this is a simple project, what are the parameters for a “real” project? Can’t just claim 1 and done!
  • That’s moving the goal post down the field. You should be careful when doing that, they weight over 1,100 lbs. Make sure you life with your knees. The question posed was “How can you make decisions – in the presence of uncertainty – without estimates?” Nordstrom answered it with their video. They made lots of decisions with a burn rate, a story map, and a timebox.
• Can this apply to larger projects? Possibly. What I outlined above could be a way to go. I’ve worked that way with in-house IT teams and did well with it.
• Can it work for consulting firms or work for hire? No idea. I’ve never been a consultant.
• What about domains with regulation XYZ? No idea. I’ve never been subject to regulation XYZ and I’ve probably never worked in your domain.
• Would you deploy ERP this way? Nope! I’m not sure that agile is the right approach for highly coupled massive initiatives like ERP deployments. YMMV

Last, but certainly not least is one of my favorite questions:  “Isn’t the team making implicit estimates by slicing work in relation to a 1 week timebox?”  Sure. Feel free to claim the win with the “everything is an estimate” argument.

BUT in the scenario I laid out, the estimate/forecast is a by-product of the work being done.

This subtle difference is critical to teams successfully delivering software with agile practices.

[reminder]I’d love to hear your thoughts on the video. Please leave a comment below.[/reminder]