Agile teams favor a just-in-time approach to requirements. In place of a lengthy requirements document, we use feature descriptions that are minimally described, progressively refined, and stored in a product backlog.
User stories are the best way I’ve found to capture just enough information about a
feature to facilitate a future conversation between the product owner and the team. User stories are descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.
User stories typically follow a simple format:
“As a [type of user] I [want/can/am able to/need to/etc.] so that [some reason].” Though that format has its advantages
, user stories can be in any format, so long as the conversations surrounding the stories occur. User stories come in different sizes. A small story, called simply a “user story,” is one that is well understood and can be implemented within a sprint—something like: “As a manager, I want the monthly sales report to be paginated so that I can quickly refer to a specific part of the document.”
Large user stories are typically referred to as epics. There's no magic threshold at which we call a particular story an epic. It just means “big user story.”
Epics generally take more than one or two sprints to develop and test. They are usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them.
Building on the monthly sales report analogy, an epic might be: “As a sales manager, I want to see sales broken out by region.”
We call large stories “epics” to communicate something about them. I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There's probably some car chases, probably some shooting, and so on. Similarly, calling a story an “epic” can sometimes convey additional meaning.
Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “But they are mostly epics.” That tells you that while I did write them, I didn't get the chance to break most of them down into stories that are probably small enough to implement directly.
One more term is commonly used when talking about user stories: “theme.” A theme is a collection of related user stories. Let’s say I write a group of stories about monthly reporting that all have to do with formatting. By giving those stories a theme, let’s say “Monthly Report Formatting” we put a virtual (and sometimes literal) rubber band around the stories and can refer to them as a group.
Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme.
Story, epic and theme are merely terms we use to help simplify some discussions Scrum teams have. They have standard meanings that date back to some of the earliest XP teams. And it's nice to use terms in industry-standard ways.
But, you can make up your own if these don’t work for you. Don’t lose sight of the fact, though, that these are just terms, and the most important part of a story is the conversations it creates.
Do you want one short tip each week
from Mike to help you succeed with agile?