Epics, Capabilities, Features and Stories - How BAs communicate Agile requirements
If you’re new to Agile, maybe moving into a company that uses a larger structure then what you’re used to or if you’re at the start of your BA career and getting familiar with the basics, then this article is for you.
We will take a quick, high-level, look at each of the most common work items within Agile and put together an example of each requirement and what may be the deliverable that forms the solution to help visualise what each work item represents within the whole structure.
Epics
The Epic, the largest work item in common use.
The purpose of an Epic is to provide the birds eye view of what the product (or project) is going to be. It should set the initial guiderails for everything else that follows (i.e. scope setting or direction setting). This will often be a very large piece of work that can take a year to complete. Another use for an Epic is to ring-fence a Product from the rest of a wider portfolio.
To help visualise this work item type, we’re going to run a hypothetical set of requirements and what the deliverables might be for them.
For the Epic we’ll have a requirement at a really high level, something like ‘The customer needs a place to live’. At this level we’ll include a budget at have identified what sort of segment our customer will be in (e.g. the customer’s own budget).
As our deliverable, the solutions team could come up with a home, a caravan, a houseboat. There’s all sorts of options but we’re going to continue this example with the deliverable being a home.
Capabilities
Capabilities are the rarest of the this hierarchy work items and tend to only be located in companies that use SAFe. When working on large projects these can be used to group work in a logical manner such as the User Management area or Reporting area. Within SAFe they are used to house work that will be delivered by multiple release trains and should be completed within one Programme Increment (Program Increment if you’re SAFe 5.1 or Planning Interval if you’re SAFe 6).
When looking at our visualised model then the requirement for a Capability would be ‘The customer needs to have an indoor space’. When we look at the deliverable for this then the house part of the home would be the easy option; however it could also be a granny flat, maybe even a summerhouse.
The second Capability under the Epic could be for the outside space, where the deliverable would be a garden.
Features
The Feature is one of the most useful work item types due to its size to level-of-detail ratio. This is because the Feature is really starting to get into specifics what we’re doing but is also at a high enough level that we can also see the bigger picture of what is happening. In the world of SAFe a Feature must be sized so it can be delivered within a single PI which is a period of 3 months if you’re not practising SAFe this is still a good time limit for delivering a Feature.
Going back to our example, a Feature would be along the lines of ‘The customer needs an area to prepare food’. The logical delivery for this requirement would be the kitchen, however someone more creative then me can probably think of another solution.
Other Features would be things like ‘The customer needs somewhere to sleep’, ‘The customer needs somewhere to wash’ etc.
Stories
The Story (or User Story) is probably the most famous of all the work item types. It describes a single, small item of functionality. The key thing to remember with a Story is that it should be deliverable on its own and still make sense as this standalone deliverable. It must also be small enough to deliver within a single sprint.
When writing Stories, the INVEST principle is always worth applying to keep your Story quality high.
Going back to our theoretical example, our Story would be ‘The customer needs to be able to cook food’ with a solution of installing an oven or adding an air fryer. Other Stories within our kitchen Feature would be ‘The customer needs a place to store cold food’, ‘The customer needs to be able to make a cup of tea’ etc.
Summary
Now we know what each work item type is and we can see how they all come together to form a complete Product/Project. A place to live for the customer was delivered as a home, an inside space was delivered as the house, a place to prepare food was delivered as a kitchen and finally a means of cooking food was delivered as an oven.
This is of course a simplistic view of the entire setup and we haven’t gone into proper detail on each work item, how information flows from the parent work items to the child items or even mentioned Acceptance Criteria; those are all for other articles.