Agile Prioritization

Your company is building out a toolkit to support third-party developers. You'll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc. You've got a long list of desired controls from your customers. You're agile. What do you build first?

Agile In a Soundbite

Being agile is about delivering incremental value, quickly, getting feedback, and then delivering more incremental value. Repeat until "done." Good agile adds a qualifier – do the most valuable thing quickly, get feedback, do the most valuable thing (that has not already been done) quickly. Better agile optimizes the rate at which you deliver value by taking into account both benefit and cost. Great agile overlays a focus on getting better at doing all of these things while you do them – becoming a learning organization.

Boiling the Ocean

A product manager I was coaching was faced with a challenge commonly referred to as boiling the ocean. His team was tasked with solving a market problem, and they were constrained to doing it with a service-oriented architecture that exposed a set of widgets (user interface controls) that customers could easily integrate into their products. This approach was designed to provide competitive differentiation by reducing the time and cost to deploy solutions that allowed customers to integrate his product into their existing platforms.

In initial conversations with customers, technologists, and architects, this product manager quickly amassed a list of desired widgets (controls) and scenarios (stories) in which they could be used. The product manager's team had recently switched to an agile development methodology. The internal stakeholders, not yet accustomed to agile development, wanted "all of the widgets," now.

This product manager was able to convince them that the team would deliver the widgets incrementally, following agile principles.

His question was – How do I sequence the widgets in the backlog?

Defining Widget Priority

The product manager had a list of widgets, combo-boxes, data-grids, text fields, radio buttons, etc., and for each widget, he had a real-world scenario showing how the widget could be used. Most of the scenarios involved customers using multiple widgets. He wondered if he should do some sort of analysis that detailed the frequency of use of each widget. "This widget is used in 7 scenarios, so it should be done first; this widget is used in 5 scenarios…"

There was a strong temptation to add several "Create a widget" tasks to his backlog. It would be easy for his development team to estimate the effort required to deliver each widget. His team wanted to deliver incrementally, and "one widget at a time" felt like logical, discrete chunks of work to them. They could easily sink their teeth into estimating, building, and testing each widget.