Agile teams are action oriented. They get things done. They chop through even the biggest jobs, making incremental progress and bouncing back from difficulties.
Well, the successful ones do.
Many more agile teams are bogged down, despite the stand-up meetings, burn-down charts, and Kanban boards. These teams finish iterations with half of their promised user stories not done. They morph the meaning of “story points” to be whatever it takes to give managers the anticipated velocity number. They are going through the motions of agile but not realizing its benefits. They’re lost.
Other would-be agile teams experience problems getting started. They’ve read about XP and Scrum, and maybe they’ve even had some training, but every starting point they consider raises questions they can’t answer. So, even though they keep on studying, analyzing, and talking about agile, they are in fact locked out.
A well-crafted agile story acts as a beacon that lights up the pathway where an idea becomes an action. The story can clear the fog for teams that have lost their way and can provide locked-out teams with enough of a line of sight to customer value for the teams to proceed with confidence. What does a well-crafted agile story look like? As Brian Marick is fond of saying, an example would be handy right about now.
Need to get electronic patient signatures
Get electronic patient signatures.
As a Nurse, I want to capture electronic patient signatures and related bar codes for better record keeping and billing.
Conditions of Satisfaction:
Figure 1: A story before and after storycrafting
The version of the story in figure 1 that’s on the right-hand side is more useful in helping the team actually achieve what it set out to do because it gives just the right, concise specifics. This version is an end result of a storycrafting session. Storycrafting isn’t a set of rules or even a defined set of questions. It’s similar to a conversation but with some goals along the way that need to be addressed. We’ll look at each of these goals within this article in the form of a question.
But wait a minute. Do we need yet another agile practice? Isn’t this just another name for Ron Jeffries’ “Card, Conversation, Confirmation” concept? No, it’s a bit of guidance for having the conversation and for laying a foundation for the confirmation. For a team that has worked with a coach to write the initial stories, storycrafting acts as “training wheels” that help a team establish this new practice safely on its own. Does it work right out of the box for teams that have not used a coach? I don’t know. No one has tried that experiment, but this article is a first step.
Storycrafting has emerged from my experience coaching teams while appreciating how much difficulty they have early on with using agile stories correctly. Poorly written stories lead to many hard-to-diagnose problems, and people new to agile are by definition the least equipped to create good stories and fit them well to the context of the project.
In my role as an agile coach, I’ve worked on helping teams achieve the goal of generating agile stories that show the best paths forward. There are always multiple paths forward, but how do you choose the shortest and surest and how do you sidestep the problem of the unknown unknowns. I used a pattern of questions to prompt the project community—technical team, internal and external stakeholders, and domain experts—to supply the elements of good agile stories. Such elements include why this feature is needed by the user and how its performance can be demonstrated. In this case, “good” means that the stories can be assembled into a topology showing a few of the most promising paths for delivering customer value. Further, they are clear enough (no wiggle room) that the team members feel confident enough to perform them.
Let’s look at an example of how storycrafting techniques can sharpen the story in figure 1. A medical product company’s agile team has this story in its plan for the next iteration: “Need to get electronic patient signatures.” We’ll follow along as an agile coach (or ScrumMaster) asks a series of questions to make this a more useful story.
Question 1: If we never implement this story, who would miss it the most?
The team’s analyst says, “The billing department needs the electronic patient signatures, and right now the nurse gets the info on paper. When our handheld units can let the patient sign on the screen, then the bar code from the dispensed products already will have the signature associated.”
The coach says, “Oh, so patient signature is not the only data being collected, then?”
“We need to capture the legal disclosures that the patient signed for and the items dispensed, so that they can later be reconciled with the Biomet Product Master,” says the analyst.
The product manager says, “And there are financial disclosures, too, that the patient signs for. It would be good to also capture the diagnosis code, as well.”
Things are getting tangled now. Patient signature is the tip of a potentially big iceberg. We’ll sort out the scope of this story, but the first job is to figure out who is the main beneficiary of the story. Right now, it’s not so clear whether that is the nurse or the billing department. In this instance, more dialogue will clarify that the billing department’s life won’t change very much after implementation of this feature, because they already receive all this data, except it’s partly in paper form. But, the nurse’s job will improve because this will be a big time saver.
Stories often have more than one customer or beneficiary. Find the customer who benefits most. Then, write the story for that customer, using her role in the story. Let’s see what that looks like, starting with a classic agile story format:
As a <role, beneficiary>, I want <capability> so that <benefit>.
We might begin to write:
As a nurse, I want to capture electronic patient signatures so that...
Wait! We haven’t fully addressed what benefit we are after, so the coach has another question.
Question 2: How does this story benefit the Nurse (beneficiary)?
Note that the answer to question 1, “Nurse,” becomes part of question 2. The team members have several answers to question 2, so the coach makes a list on the white board. It looks like this:
Benefits to Nurse
Now is the time for the coach to remind the team that the story is not meant to say everything that can be said about a feature. It is a brief summary of key information. (There will be a home for all the details that are needed for implementation.) So, the coach asks them to come up with a short phrase that captures the primary benefit of this story. After a little more conversation, the story emerges:
As a nurse, I want to capture electronic patient signatures and related bar codes for better record keeping and billing.
There may be many benefits that the story can confer, but it’s important to focus on a small number of the most important ones or the ones that you need early. You can address the rest in later stories, so don’t worry about those yet.
Now, we’ve established the who, what, and why of this story. Are we done? No! The next question is crucial.
Question 3 (to the product owner): If the team came to you tomorrow saying, “The story is done. Will you sign-off?” what would prove to you that it is really completed?
The product manager and the business analyst start making a list on the white board. It gets longer and longer. It’s time for the coach to remind them that only a handful of key items is needed. Don’t try to write the full set of test cases or address the error paths here. Later stories can build upon this one, addressing edge cases and the needs of other roles.
On another white board, the product manager writes a small set of conditions that must be satisfied for him to sign-off the story:
Conditions of satisfaction:
The most valuable thing about these items is that they are in the customer’s language. I find that people from product management or marketing are usually good at being concise. When you ask the question in this way, they seldom have trouble stating clearly and briefly what must be demonstrated.
Conditions of satisfaction tell us about the boundaries of the story—the constraints that are in force. They tell what must be demonstrated, how much must be demonstrated, and how accurate it should be.
In this project, the handheld units already exist and standard screen templates and data formats are in use. Testers and the product owner will work out further detail about the screen layouts, data formats, and so on during the iteration. In other words, there is confidence that the remaining details can be worked within the iteration where this story is implemented.
In another setting, there might be more uncertainty about those details of screen layout, navigation, interfaces to other systems, and so on. We’ll go deeper into the question of how to deal with unknowns later on.
Question 4: Are we done writing this story?
Stories evolve. They may start as just a phrase, like “Need to get electronic patient signatures,” but they need to be developed to a certain level before the team will be able to estimate them. (Some teams do not estimate stories. They simply queue them up and work them as needed, sizing them in retrospect, if at all. Whether the next step is story estimation or implementation, the point is the same: The story has to be fleshed out in preparation for it.)
We are done with writing this story when it is clear enough for the team to be able to estimate it. As mentioned, this does not mean every detail has to be spelled out. But, choices that affect the size of the work must be made. Suppose that in the patient signatures story, the product manager said to the team, “The screen text will be either just English or user-configurable to one of eight languages.” That difference would greatly affect the size of the story. So, pick one and state the story unambiguously. There is no “mystery meat” in a proper agile story!
It’s OK if you want to ask the team to give an estimate for two different versions of the story. Write the two stories, but make each one unambiguous.
To tell whether you’re done writing the story, ask whether it is clear enough for the team to estimate how much work it entails. The “No Mystery Meat” rule is important, because we need to prevent backsliding. Chip and Dan Heath address it this way in Switch:
If you’re worried about the possibility of rationalization at home or at work, you need to squeeze out the ambiguity from your goal. You need a black-and-white (B&W) goal. A B&W goal is an all-or-nothing goal, and it’s useful in times when you worry about backsliding. Maybe your B&W goal for your alcohol consumption could be “No wine ever.” No wiggle room there. And what if we changed our New Year’s resolution from “Be healthier” to “Gym every day” or even “No more Cheetos”? Those goals leave nowhere to hide. Either you’ve got damning orange Cheeto dust on your fingers or you don’t.” 
This patient signature story evolved further. During discussion of the acceptance criteria later on, the team and stakeholders decided to drop these items from the conditions of satisfaction:
That decision was made some days after the storycrafting session, when they met to estimate stories. It became clear that having the story completed sooner was more important than having these two elements.
“What?” you might say. “Skip data entry validation? That’s not high-quality code.”
It’s OK to put the data entry validation work into a later story, so long as the team and stakeholders recognize that fact. How? By not deploying the software until that feature is implemented or by taking extra steps to compensate for the missing data validation feature. Another option is to code this story without data entry validation, unit test it, and then disable the whole story until the postponed parts are implemented.
These are all valid paths to consider. This is what it means to assemble the stories together to form a pathway to customer value.
We’ve now followed the example of transforming a fuzzy agile story into a crisp, useful story that has strong safeguards against backsliding (no mystery meat!). We’ve seen how a pattern of questions tested the need for the story (who benefits?), determined the benefit, and established ahead of time what will be acceptable proof of the new capability. The questions provide vision for one strand of the work to be done.
The next parts of this article will address these questions: