An epic vs story vs task is one of the most common misunderstandings in Agile project management. Both are related to delivering business value but at different granular levels. User stories are epic’s decomposed to a level that the software development team can work on it.
Epics are a group of user stories grouped together to achieve the same business goal/product.
User story is a requirement or agile feature written in the viewpoint of the end user and follows the following format.
Tasks are pieces of work that support the completion of a user story.
Each level has different stakeholders. At an theme/initiative level you would have project managers and product managers interested in delivery. Product owner would be responsible for creating the epics to help achieve the outcome. The product owners also decompose the epics into user stories with the product team leads such as designer and engineering leads. The tasks to complete these user stories is the responsibility of the engineering team who actually are doing the work.
Example of Epic vs User Story vs Task
I’m going to take the example of creating an ATM which is represented in the below image which is splitting up user stories in verticals and horizontal. They are demonstrating user story slicing technique. Some might consider the epic to be create an ATM and then individual features as user stories, which works in theory but not practically.
Create a cash withdrawal feature will have a number of scenarios it should meet. It should have a balance reader, security checks, ledger of cash available in ATM, access to users personal details, audit trail etc.
When writing up requirements these would generally start at an epic level. Take the example below you want to build an ATM. The product manager would list out the features the ATM should have. One of the features such as Bank Statement should be considered an epic as it is a large piece of work that will consist of multiple user stories.
I think of user stories in simple terms as user scenarios. You list the scenarios that each user will want from the feature. You can have multiple different users. For the ATM bank statement you have the end user but also internal users such as compliance team, fraud.
As a user, I want to download bank statement so that I can view my balance .
As an compliance administrator, I want to monitor bank statements printed so that I can confirm they are accurate.
The story format leaves the actual technical implementation up to the developer. Stories will be reviewed in refinement sessions to ensure the development team understand the user requirements and the expected behaviour of the end product.
Task are created by the engineering team. Task would generally be technical tasks such as testing, security requirements, dB work etc. These fulfill all the needs of the user story.
User Story vs Tech Story
User stories are from a user perspective. A technical user story are technical pieces of work that need to be completed to complete thew epic. This are on same par as user stories as they need to be estimated and equal priority to user stories.
Bug vs Task
A bug is where a feature is not working as expected or when a user story doesn’t meet the definition of done. A bug can consist of multiple tasks that are required by different people to rectify the issue. Tasks could be db update, new design etc each for different people to complete.
Definition of Done DoD
When a user story item is “Done” everyone must understand what “done” means as this can vary from scrum team to Scrum team. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.
If there are multiple Scrum Teams working on the system or product release, the development teams on all of the Scrum Teams must mutually define the definition of “Done.” The Definition of Done is the standard for expected quality of the team and would be expected to expand to include more strict criteria as the team evolves.
Estimating Epic vs Story vs Task
These all combine together to deliver a theme or initiative. We decompose these to make them more manageable increments of work. Each are estimated with greater levels of accuracy as we you go deeper into levels. At an theme or epic level you should consider agile t-shirt sizing.
We use t-shirt sizing as its relative estimating comparing epics against each other. We try to do a similar technique for user stories using planning poker and Fibonacci series. These estimates prevent project managers from trying to put time pressure on individuals to deliver. At a task level though we are asking for estimates from engineers on tasks they are familiar with. This is agile version of bottom up estimating.
The reason we don’t start with bottom estimating is that with agile we adopt rolling wave planning so as user stories aren’t written up front as we should be working on most important thing each time and avoid large requirement gathering and estimation sessions. This is waterfall not agile.
Agile Epic Template
We have listed 9 free epic templates in this article but you can also use our own free google doc version below:
