Use Case Driven Agile Development

I had been to Netobjective’s seminar “Transition to Agile” about two years ago, so I knew this month’s talk on “Use Case Driven Agile Development” (August 15, at De Anza College) was likely to be good. It was very good. Dan Rawsthorne is a good coach.

During his two hour talk, Dan gave what he calls a “low precision, sunny day-version of the truth”. Here are some brief notes on the first part, the Essence of Agile.

First, for whom do we (or should we) develop:

  • Ultimate end users
  • Maintainers
  • Whoever pays for it

Agility is about paying attention and reacting. You can’t not make mistakes. What you can do is figure out you made a mistake quickly and react accordingly.

According to studies by The Standish Group, an average of 45 percent of any given product will never be used. It’s complete waste. With agile development you are trying to avoid that kind of waste. The magic of project management then, according to Dan, is to redirect the resources used to build the stuff that’s not needed towards the useful things that we don’t know about (yet).

Here’s what you should aim for in an interative product development cycle:

  • 1. iteration: build the 7 percent that’s always used.
  • 2. iteration: build the 13 percent that are often used.
  • 3. iteration: build the 16 percent that are sometimes used.
  • 4. iteration: build the 19 percent that are rarely used.
  • 5. iteration: no development here, just avoid the 45 percent that are never used!

Of course, one can never fully achieve this, but keep it in mind while you’re trying.

A brief summary view of project management:

  • Goal: provide a suitable solution for users that consists of quailty code and doesn’t cost too much.
  • Ideal: convert effort you would spend unwisely into developing things you don’t know about yet.
  • Common strategy: get your money, then spend it wisely.
  • Implementation: we claim this requires an agile process.

The essence of agility:

  • iteration
  • validation
  • feedback

The important thing about agility is doing everything in small, easily validated chunks. Validate that the chunks are the right ones and that we have accomplished them. So, a process is amenable to agility if it can be decomposed into small chunks, each of which can be validated.

Interesting note about the half life of requirements. We all know requirements go stale after a while. At a rate of 3 percent per month, that means a 100 percent change over a 3 year project period (or maybe one third of the requirements change three times over the course of the project). Why? The universe changes around your product. Even if you knew your requirments perfectly they’d be wrong after a while.

One of the “good” team philosphies leading to agile is validation centricity (validation is any activity that lets you know you’re doing the right thing and you’re doing it right). Activities of validation, verification and test are more important than those of analysis, design, and construction (some agile teams validate as often as twice a day!).

And finally, let the product lead: decisions must be based on the product, not documented plans, anlyses, requirements, or designs.

Download the seminar notes (PDF).

4 Responses to “Use Case Driven Agile Development”

  1. Planblog » Blog Archive » The Benefit Gap (What’s missing) Says:

    [...] use what we have. Ties in neatly with the findings of The Standish Group (mentioned here: Use Case Driven Agile Development), according to which an average of 45 percent of any given product is was [...]

  2. Jürgen Ahting Says:

    The original source for the Standish findings you refer to is an invited talk of James Johnson, Chairman of The Standish Group, at the XP2002 conference. While I was there, it’s difficult to find on the web anymore (look here).

  3. Tim Says:


  4. Kevin Says:

    I would like to understand the original source of the half life of software requirements. Can someone point me to the source of that information?

Leave a Reply