When Alistair Cockburn says something like:
"There is no such thing as 'agile specification'. The phrase is a hoax."
This is exactly the kind of discussion we had at the Agile Manifesto meeting in 2001. It means there is something really interesting to talk about. First, read why Alistair says he still uses use cases.
At PatientKeeper we have "Agile Specifications" which are similar to Alistair's use cases for new functionality. We require that they clearly specify the user experience with detailed screen shots, workflow, business logic, and data descriptions. We want just enough specification and a dialogue with the developers to determine how much to document. For simple things, a users story may suffice.
Problem: You will implement over a thousand user stories over many years at random times. Very tight precision is required for screen shots, flow, and business logic as a error could kill a patient. Or a physician could call it "crap" and refuse to use it.
Forces: Physician users require an exact fit to their workflow, their inferencing from clinical data, in minimal time while standing in front of a sick patient using their iPhone for all clinical data. Developers have no idea exactly how this should look to a physician. Neither does the Product Owner, even though the Product Owner may be a physician. A carefully selected group of physician thought leaders must use working prototypes to determine exactly how it should look and feel to the physician while coming to a consensus and developers much exactly create their chosen approach or physicians may refuse to use the product. Physicians will not use a mouse. Most things must require one click and anything requiring more than three clicks will never be used as it will interfere with conversation with the patient. Any data corruption is life threatening. Lack of ease of use is life threatening.
For example, a small amount of the clincial data is lab results. There are dozens of lab tests, each producing a complex data set with multiple values and normals ranges. There is interaction between these results. Automatic alerts for critical conditions based on a complex relationship between multiple lab results is needed. These are regularly updated by clinical boards that determine best practice. All lab tests are graphed differently to exacting specification taught in medical schools. Often new lab tests are required. They are based on research data developed in labs. The developer must be able to quickly review all previous implementations of all lab results to fit this new result into the physician's workflow in the correct way. The physical implementation of the current product is not sufficient for this purpose.
Solution: The Product Owner creates a dccument that is just enough, and just in time called Lab Tests. It grows over time as there are more lab tests, and as research data influences lab test results. The Product Owner does high level analysis of screen shots, workflow, data structures, business logic and presents it as a very light weight use case to support user stories implemented at a point in time. The Product Owner has tested a fully working prototype of this implementation on a group of physician thought leaders before any story for these is ready to go into a Sprint. Developers refuse to develop any story that does not achieve this "ready" state. In fact, they are told to take the day off if the Sprint Backlog is not "ready."
Result: Over eight years and thousands of stories the global specification has grown to almost thirty pages. A developer can capture in his mind in less than five minutes the entire history of implementation of all lab results that is essential for implementation of a new blood test for treating diabetic patients.
The Product Owners are extremely disciplined in this environment. They know developers will take the day off if their "Agile Specification" is not in a ready state for creation of user stories in a Sprint.
The Team is also very disciplined and achieves a velocity that is 10 times as fast as their waterfall competitors causing revenue to quadruple in 2007.
Name for this thing: Up for grabs.
Need for this thing: Absolutely essential or you will risk killing patients Or even worse, the physicians will refuse to use it declaring it "a piece of crap" or it has too many alerts or does not alert to a critical condition on this lab test in the context of certain data on multiple other lab tests. Or it does not automatically populate the right clinical notes, or the developer is clearly so clueless about treating patients that he should be shot, or ....
Best training for developers: Send them to surgery where patient is opened up on the table and the surgeon starts screaming at him and the surgical staff making threatening gestures to hit them with surgical instruments for providing the wrong data leading to his decision to abort the surgery and try again at another date when they give him the right data and the right instruments at the right time when the patients lab results are exactly in the right constellation for the surgery to take place.
Jeff Sutherland
English 
French 
Spanish