Differences between user story, epic, theme and task

Differences between User stories, Epics, Themes and Tasks.

1. User stories

In an agile environment, we start from a product backlog. This product backlog basically contains user stories that will be developed by the developers in a number of iterations (sprints). A user story tells us something that is required by some people to be able to do something and this results in a certain business value.

Traditionally, requirements are analyzed in detail; a user story however passes some stages before it results in a detailed analyses.

The basic concept we use is based on the 3C methodology. The 3Cs stand for “Card”, “Conversation” and “Confirmation”.

1.1. The Card

This contains a brief description of the need. Here I use the 3W-concept.

Meaning, for “Whom” is something necessary; “What” is needed and “Why” is it needed, what is the business value of it.

So, in fact, we use a template as:

“As [whom], I want [What], so that [business value]”

Advantage of this way of working is that it is easy to write for everyone, it contains in a brief way all what is needed and gives us an indication of the value of this story. Stories without business value will probably end up in the garbage since they have no added value. This way it is easy to write stories for everyone in a structured and understandable manner. This way of representing the story is often called “The Card”.

The card is often used as a kind of postage representing the story on the scrum board.

Some examples:

As user, I need to have a list of all the actions needed to realize today because this gives me my action list for today’s work
As manager, I need the action list of all my workers to be able to follow-up their work.
As Operator, I need to manage user information so that I can give them the necessary access rights.

With the card we obtain now a lot of useful information resumed in 1 single phrase. However; this is not the full story. You need more information to be able to document the full story; what has to be made, how it functions, what further actions will be needed. The first step in obtaining that information is called “The conversation”.

1.2. The Conversation

The conversation is like the word it selves explains, is a conversation between the product owner/stakeholders and the business analyst/team. Product owner explains his needs and what the requirements are, how it should work, what kind of restrictions there are; the analysts/team asks questions to fully understand the demand in detail so that they are able to estimate and develop the requirements. You should try to write down these requirements and actions needed in a kind of IMAP(Information Mapping) based bullet list form.

At this point, once we are able to fully understand and estimate the story we might conclude that this story is too large and that it should be split into several other stories. That’s where the “Epics” come into place. Epics is a container of different related stories. It is a story it selves but is too large to be handled as 1 story within a sprint. Usually these stories are split into separate smaller stories until the realization of it fits within a sprint. You don’t split the stories to a granular level of stories of 1 hour but try to find a good balance between usability and effort to document your stories. I take as a guideline that a story should possibly be realize between half a day and 10 days.

Of course, as agile coach I will never count or plan using time units (hours/days) but I will use relative story points estimates. So stories of less than 1 point for me are to small entities and stories of more than 20 story points should be split into smaller entities.

In case the conversation is rather complex to document, you could use some mock-ups to visualize the requirements and use them as a basis to start your conversation with. This facilitates a lot the dialogue and gives you the opportunity to take notes on the mock-up directly. The product owner, this way, gets also directly an idea of what he can expect to be realized and how it will look like.

In order to describe your stories consider following guidelines (also called INVEST)

INVEST

I stands for INDEPENDENT. Each story should possibly be developed in any order. Meaning that it should be possible to start developing with the story as well as to keep it for the last one to develop.
N stands for NEGOTIABLE. User stories should be written in a way that it gives both parties the possibility to negotiate if needed about different aspects on the story. Fact is that based on budget constraints it should be possible for both parties to negotiate if a requirement or a specific detail in the story should be implemented or not. So one advice, don’t make stories that go to deep into detail.
V stands for VALUABLE. Meaning that a user story should have some business value. If you create stories without value then you create something not worth creating it. You better drop the story then. Agree upon it with your stakeholder. No added value is only a cost or a nice to have.
E stands for ESTIMATABLE. The story should be as clear as possible to enable the developer’s team to make adequate estimates. When using the planning poker game to estimate and you receive to high differences in estimates, you can be sure something is not clear in the story.
S stands for SMALL. As explained already, keep the stories small but not too small. It should be easy for the team to plan and estimate a story.
T stands for TESTABLE. A story should be testable. I come back on this in next point “Confirmation”. What is important for the team is that a well described definition of done is available so that it is clear to everyone in the team when he can put his story to “done”. In order to test and validate a story and to quickly analyze if a team understands the story well; we consider the third part of the 3C structure of the story to be filled in by the team. Here they will write down how they will test the story.

1.3. The Confirmation

I my case, confirmation has several purposes. The idea is that the developers write down the way they will test this story.

This enables us to:

The developer to fully understand and analyze the story.
See if the developer really understood the to do’s in the story
See if nothing is missing.
Give the product owner some feed-back and ensures him that everything is understood and will be tested as required.

2. Epics and Themes

An epic is simply a large user story. It is a user story that is too large to be handled in one single sprint and therefore should be split into smaller parts; smaller user stories. Compare it with a trilogy of books. A book can then be considred as an Epic and a chapter as a user story. You can easily read smaller chapters than read the whole book at once.

Themes are a group of related user stories. For example all stories related to user management or related to security could be put together in a theme “user management” or “security”.

How do I use both terms in practice? Well basically I only use the term Epic where I have user stories that rather relate to a theme. In other words I start from a theme and drill down in my analysis to a user story level.

3. Tasks

Once the story is clear, confirmed, estimated and can be planned; the developer’s team takes the stories and split them up into smaller tasks. These are the different steps in which they will plan to develop certain functionalities of the story; these tasks are handled by the team it selves. They are part of the story to develop. In extreme cases you could even drill down to a level of sub-tasks but I will not encourage you to do so. I always maintain the KISS principles; try to keep it simple.