02.08.10
Why Use Cases Rock
Typical agile-style use cases rock. Really.
There’s a pretty common pattern for them, so common that it’s a part of the whole Behavior-Driven Development idea. It’s just: “As <role>, I want <feature> so that <benefit>.”
A lot of people seem to think that this is overly simplistic. I respectfully disagree. What this simple format does is tell us the most important things about anything we do, in a way that pages of details about the implementation don’t.
As <role>: Tells me who the customer is. And who the customer is tells me a lot about how I need to expose functionality.
I want to <feature>: describes what the customer wants. This is typically where we spend the most effort.
so that <benefit>: The business value of what we’re doing – why it’s important.
Simplistic? Maybe, but it does a much better job of reminding us of who our customers are, and what the business value that we’re trying to produce is, than any other format I’ve seen.
And, frankly, forgetting who our customers are, and not focusing on business value seems to be a far more frequent problem than not spec-ing features sufficiently up front.