Capabilities are the things we talk about with our stakeholders, and we talk about them in the stakeholder’s language. Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.

Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders are thinking in and it’s is what they will use to understand the product we have built.

As we know, stakeholders can ask for virtually anything. Therefore, capabilities can be virtually anything, from small bugs that he be fixed to extremely large wishes and dreams. For example, each of the following statements describes a capability:

• Remove the extra linefeeds in the presentation of the list of flights on the “Choose a Flight” page (a bug);
• I want to be able specify that I need a special meal for my flight (a new feature); and
• Make it faster (an extremely large, ambiguous request).

What’s important to know about capabilities is that the priorities of the capabilities derived from the stakeholders, even though they may be modified by dependencies that the developers see. Since scrum is all about having a prioritized list of things to work on, we can see that most of the priorities that we derive from the stakeholders.

What we are usually trying to deliver in a release is a releasable capability. This leads to concepts that we find in the literature such as Minimal Marketable Feature (MMF), Minimal Releasable Feature (MRF), and so on. Even though I won’t discuss it, I think that for scrum what we really need to produce is Minimal Demonstrable Features (MDF), as the basic concept of scrum is to inspect and adapt, so we need to produce capabilities that we can demonstrate in order to get feedback.

In particular, we will discuss the following terms: capability, chore, story, epic, and task. There tend to be natural comparisons and pairings in this set; for example, capability versus chore, stories versus epic, and story versus task. Each of these issues will be discussed as we go along.

But first, a quick review of fully know about Backlog Items, or PBIs. Basically a backlog items is anything the lives on the backlog; it can represent work to be done, issues to be discussed, or problems that we have. In any case, a backlog items is a token for future conversations, that progress from the moment we know about the backlog item until the work it represents has either been completed or discarded.

The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.

In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.

Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.

Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.

Some examples of epics are:

•        “We want the system to be able to manage the pilots’ schedules”;

•        “We’re going to need to train all our users on this new release”;

•        “As a <tourist>, I want to <fly to Catalina for the weekend>”; or

•        “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.

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:

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.