Epics, Features and User Stories

Where to start with these 3 agile work item types?

There’s so much confusion out there around what exactly each one entails, and whether user stories are the same as features or if epics are user stories. I thought I would lay it out as simply as possible in line with Microsoft Azure DevOps (VSTS) (I am a huge fan of Microsoft’s suite of software these days — but that’s for another day).

For those who don’t know agile is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans, this reassessment generally takes place in two week time units called sprints.

Microsoft defines them as follows:

Epics

Epics declare initiatives important the organizations success. Epics may take several teams and several sprints to accomplish, but they are not without an end. Epics have a clearly defined goal. Once attained the Epic is closed. The number of Epics in progress should be manageable, to keep your organization focused. Epics are broken down into Features. Many organisations introduce a level above Epics called Initiatives, Initiatives break down into Epics.

Features

Features define new functionality required to realize an Epic’s goal. Features are the release-unit, that is, they represent what is released to the customer. Your published release notes can be built based on the list of Features recently completed. Features can take multiple sprints to complete, but should be sized to ensure a consistent flow of value to the customer. Features are broken down into stories.

Stories

Stories define incremental value the team must deliver to create a Feature. The team breaks the Feature down into incremental pieces. A single completed story may not provide meaningful value to the customer. However, a completed story represents production-quality software. Stories are the team’s work unit. The team defines the stories required to complete a Feature. Stories optionally breakdown into Tasks

Tasks

Tasks define the work required to complete a work item.

Still confused?

To put it even more simply it is often better to approach this understanding with a bottom up approach — starting with the User Stories. Requirements are often defined by what output the user would like to achieve, so it makes sense to start from there and work your way up through the functional areas.

User Story — A user story describes what the user would like to achieve during a certain interaction with the software.

User stories generally follow the following format:

As [persona] I want [what?] so that [why?]

Features — the user stories gathered together into their relevant functional areas.

Once all the user stories have been identified they can be grouped according the functional area they have in common, this will become the feature. For example, all the user stories that happen in the checkout process of an online store will fall under the relevant point in the process.

Epics — are the overarching project master, that as stated earlier have an end.

The epic can also take the form of a user story that expresses the expected outcome of all the various features and steps required to get the project completed. It could also just carry the project code name.

Tasks — the most granular level of explaining how to get work done. These can almost be written in a step by step way. The idea behind tasks is that the person who comes after the person who came before will know exactly how to get the work finished.

Tasks can be attached to any parent item, epic, feature or user story, and in operations to the Bugs and Issues.

Who owns what?

In our project environment the epics, features and user stories belong to the analysts, and the tasks belong to the developers.

Put simply, epics features and user stories are functional elements and tasks are the technical work units.

Our process for assigning work is as follows:

1. Analysts create work items in line with the specification documentation.

2. Analysts assign each work item (epic, feature or user story) to the developer responsible for doing the work — this can be split depending on the developer’s stack.

3. Developers create the tasks required to complete the work and close each one as it is completed.

4. When all the sub-tasks are completed the developer closes the parent work item and it gets reassigned to the analyst.

5. Once all children of the master work item are closed the project can move to testing.

The reason we create the work items in line with the specification documentation is to ensure that our clients can understand the projects progress and map it back to what they have agreed and signed off.

Mapping the documentation to agile

Our approach is simple, we follow agile in DevOps (VSTS).

Our documentation is structured to ensure that when broken down into DevOps agile work items it conforms to the predefined DevOps fields. The most useful of these is currently the success criteria in user stories as these will later become the test cases against which the agreed functionality is validated.

If you haven’t tried DevOps have a look, you won’t be disappointed — and I’m not affiliated to Microsoft in any way, so I have no ulterior motive.