Story
The most important unit of work that a scrum team does is the Story. The story is a small unit of work that the team does “all at once” and is used to provide either capabilities or chores. Even though some capabilities are small, and delivered with one story (bugs, mostly), most capabilities are delivered only after the development of many stories.
In general, a story is simply a request for the team to do something of value. This does not mean releasable value; that’s what capabilities are for. It does mean demonstrable, testable, verifiable value, as we need to be able to be able to inspect and adapt based on the results.
A story is an extension of the user story, which was introduced in eXtreme Programming (XP), but we don’t restrict stories in scrum the just the ones that user value. This is why we just call them “stories”, and often add a modifier, like “analysis story” or “infrastructure story” or “development story”.
In spite of the fact that not all our stories are user stories, it is useful to look at the INVEST acronym, which Bill Wake originally introduced to describe “good” user stories:
|
Independent |
Stories should be internally independent during their execution; that is, the success of one story should not depend on the success of another being done at the same time. |
|
Negotiable |
Stories are the negotiation units in scrum. It is stories that are committed to in planning and that are delivered. In addition, the actual content of a story is negotiable during development. |
|
Valuable |
Stories are, by definition, units of value that are requested by stakeholders or team members. The value can be external or external – providing value to stakeholders or to the team. |
|
Estimable |
The team needs to be able to commit to the story, which usually implies that the story’s effort could be estimated. However, some stories are so ambiguous that they must be time-boxed. |
|
Small |
Stories should be small enough that there is little confusion about what they mean, and so they can be completed relatively quickly. I recommend a single focus per story. |
|
Testable |
Stories should be testable; more precisely, each story needs to be verifiable, so that the team can determine when it is “done.” This “doneness” takes different forms for different kinds of stories. |
While the acronym needs to twist a little bit to fit when we expand the concept from “user story” to just plain “story”, the basic ideas are good. Basically, a good story is one that is small and well-understood enough for the team to commit to and not be confused by. If we are talking about functional stories, the definition of “small” the I like to use is “one thread” or “one positive test” or “one state of the system” or something like that. We’ll discuss this concept in the next chapter, when we discuss the definition of “done.”
The concept of the story is both simple and brilliant. What makes it simple is that at its core a story is just a request for something of value, and the purpose of the story is to start a conversation. The story takes the place of a requirement, but it has a completely different tone. Whereas the requirement has the tone “here’s what I want, just go do it” the story has the tone “here’s what I want, let’s talk”. As Alistair Cockburn has said “a story is a promise for a conversation”.
What makes a story brilliant is that not only does it replace a requirement, it also replaces the low-level activity; a story is not only the request for value, it is also the activity, or work, that it will take to provide the value. In practice, this means that as you are doing analysis in order to find requirements/stories you are also developing your units of work. All you have to do is add prioritization, and you’re good to go – your planning is done. Some examples of stories include:
• “As a <passenger>, I want to <be able to select my seat online>, so that <I don’t have to do it at the airport>”;
• “Go talk to the pilots and find out what they think about pilot compensation”;
• “Review the suggestions the pilots have submitted to see if there’s anything cool there”; or
• “I need somebody to spend an afternoon with the pilots, to explain to them how the pilot compensation page works”.
There are other things we want from our stories, as well, and we’ll be discussing them throughout this book. For now, though, this is enough.
