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 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”.