The discussion of how do you know what done looks like? in the agile software development world has many answers. Ranging from we'll let the customer tell us, to we have this collection of User Stories and Use Cases that tell use what done looks like.
Jens Coldweys (turn on translation) blog speaks to the use of Use Cases and Scenarios in the development of software. These Use Cases and Scenarios need a Reason for existing. This reason is usually missing or is linked to the wrong source.
- The reason we need this is the customer says we do
- The reason we need this is that any system like this has this requirement
The missing piece is not only why but the connections between the why and the actual mission outcome. By that a business mission, a government mission, a military mission, any mission.
So before the next step, let's put some definition out there:
- Mission - why we exist, why we want this system.
- Values - the guiding principles we'll use in fulfilling the mission
- Vision - the picture of the future
- Strategy - the differentiating activities that will be used to fulfill the mission
So where do these Use Cases and Scenarios come from? Good question. No answer to that question? Then these Use Cases and Scenarios have no real reason for being other than someone or some group says they want it. But that usually leads to trouble when those needs and wants themselves don't have an architecture.
- How do they relate to each other?
- What are the dependencies between them?
- Which are more important than others? This is not a ranking system, but which are more important in terms of fulfilling the mission?
The answers to these questions come from the Capabilities Based Plan for the project. This Plan states what capabilities are needed for the mission to be successful, for the system to provide the needed outcomes for the customer, for any result to fulfill its mission.
Don't know what capabilties are needed, the units of measure for those capabilities? Then any set of Use Cases or Scenarios that the user and developers come will likley be OK. This is the same problem with the requirements elicitation process. Requirements need a reason for being. A Raison d'être. Why do we have this requirement, why do we have the Scenario.
Here's how to develop those capabilities statements. Without answering these questions, those wonderful scenarios, Use Cased, User Stories have no real reason for being in the context of a "system."
