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.
The majority of the agile manifesto shines through in those 5 points. It’s a great story of a simple project that embraced agility and delivered.
But this video raised a lot of questions and criticisms. While I can’t cover all of them in this post, there were a few that I found interesting that I’ll share some thoughts on:

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]