Amazon.com 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. PlentyOfFish.com 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.