Incremental Delivery and Evolving Use Cases

books started by selling books. Their initial use case was “Sell books online.” The vision was always “Sell everything” – hence the name. But they started with a simple use case and evolved it.

Evolving Use Cases

Roger Cauvin had two very interesting posts (here and here) about versioned use cases – where he describes the idea of delivering a particular use case incrementally. Roger proposes incrementing use cases along two dimensions, features and constraints. Good articles – check em out.

Use Case Evolution

We think these are great ideas, and can be combined with the notion of scheduling releases with use cases, timeboxing of incremental delivery, and Kano-driven prioritization to structure the most profitable product roadmap. This is the most profitable approach for two reasons. First – delivering the most valuable features first is more valuable for our customers – allowing us to charge more for the increased value. Second – incremental releases of software provide incremental revenue more effectively than single releases.

Evolution By Feature

Amazon provides perhaps the most well known software example of evolving a use case by features. A former CEO of mine told a story allegedly told to him by Jeff Bezos. This CEO was known to use fiction to make a point, so I have no idea if the story is true. Here it is paraphrased:

Jeff walked in on the end of a planning meeting with the founding team of Amazon. They put together a big proposal that was as thick as a phone book, detailing how they would sell everything online – books, CDs, DVDs, housewares, groceries – everything. Jeff picked up the plan, weighed it in his hands, and then threw it across the room and into the trash can and said “how about we just sell books?”

The idea is solid, even if the story isn’t. Jeff wanted to start with books. Essentially, a feature-constrained version of the vision for the company. Over time, Amazon added products, allowing for an evolving version of the use case.

Another famous example might be the Model-T Ford – “Any color, as long as its black.”

Evolution By Constraint

Use cases getting better over time is the easiest way to think about this. Improved usability, improved performance, and increased scalability are all good examples. started with an ASP 1.0 server, allowing them to support 12,000 concurrent connections – then later upgraded to ASP .NET to support their current 500 million hits per month traffic levels – on a single webserver and single DB server! Now Markus is gearing up for a billion page views per month.

Evolution By ‘More Is Better’

The exact same semantics as the gradually tightening constraints on a non-functional requirement apply here. This is no different than evolving constraints, when the underlying parameter or attribute is represented as a non-functional requirement.


Thanks Roger for sharing a really good idea.

[Update 2006/12/13] We just wrote an article showing how to communicate evolving use cases with an actor hierarchy.

4 thoughts on “Incremental Delivery and Evolving Use Cases

  1. A little Google-searching about the start of Amazon found:

    “He first settled on the concept of catalog shopping without a catalog. He then narrowed his sights further to focus on books and music. He finally chose to just sell books at first, thinking he could get more leverage with the big book publishers than with the big record labels, even though many are parts of the same conglomerates.” at

    So, maybe it’s true, maybe the premise is true, and maybe its false – guess we’ll never know, unless one of the Amazon employees that reads Tyner Blain (I know there are at least a couple of you) knows the answer…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.