Pardon the cheesy title but I just had to!
What are Epics, Stories, Tasks?
Epics, Stories, Tasks are frequently part of the agile development process. As with other aspects of product management, different teams utilize different ways to incorporate them in their product development process.
Epic
- In a nutshell, an epic is a large user story that can’t be completed in a single sprint release – often spans multiple sprints/releases
- An epic is not technical and its main goal is to describe the use case and sometimes business case for a request
- An epic needs to be broken down into small chunks called “stories”
- An epic should contain the acceptance criteria or a Definition of what “Done” or “Completed” means
- The Product Manager or Product Owner is typically the creator and owner of the Epic
Story (also known as User Story)
- A user story is a user requirement that needs to be completed within a single sprint release
- If a story cannot be completed within a single sprint, it is too large and needs to be broken down further until it can be completed in a single sprint
- A story resides in the product backlog before being broken further into Tasks during sprint planning
- A story should contain the acceptance criteria or a definition of what “Done” or “Completed” means
- Just like the Epic, a story is not technical in nature
- A story should adhere to the INVEST Agile guideline:
- I – Independent; N – Negotiable; V – Valuable; E – Estimable; S – Small; T – Testable
- For more on INVEST, check out this post from the team at Pivotal – https://www.pivotaltracker.com/blog/how-to–invest-in-your-user-stories
- There are various approaches and formats to writing stories:
- Most Common Approach – As a < type of user >, I want < some goal > so that < some reason >
- An Alternative – Gherkin
- (Given) some context
- (When) some action is carried out
- (Then) a particular set of observable consequences should obtain
- Many have argued that Gherkin is better than the typical user story template as it is more descriptive and I tend to agree. See this post for one such argument
- The Product Manager or Product Owner is typically the creator and owner of stories
Fun fact
The concept of user stories in agile software development originated from Alistair Cockburn in 1998, a computer scientist and one of the initiators of the agile movement in software development
Tasks (Can also be a Sub-Task)
- While Epics and Stories typically define the What and Why of a requirement, a task defines the How i.e. the implementation of the requirement
- A task is a piece of work that can be delivered by an individual
- In a Sprint, a task will typically take about 1 to 2 days
- Unlike the Epic and Story, the task is technical and is typically written by the engineering lead or some other technical team member
- Some teams allow a technical product manager to write tasks; however, in some organizations, only members of the engineering team or a technical program manager is allowed to write tasks
Example: Midpoint for Google Maps
In my post on writing software product requirements, I discussed the requirements for a feature that I’d like to eventually see on Google Maps that I refer to as Midpoint. I see Midpoint as a feature that will provide a user with a halfway location when given 2 starting locations.
I’ll re-use this example to showcase how I’ll breakdown some of the requirements into Epics, Stories and Tasks. Typically, this will be done in a tool like JIRA by Atlassian or some other project management and issue tracking product.
I tend to use Epics as placeholders for large requirements before decomposing into stories. From the post, I will choose 3 Epics to highlight:
- Epic1: Allow Midpoint to be accessible with no more than one-click
- Epic2: Allow a user to select 2 starting locations and perform Midpoint calculation
- Epic3: Allow a user to choose category of meeting places
Epic1: Allow Midpoint to be accessible with no more than one-click
User Story: Provide visible icon to find midpoint between two user-inputted locations – Given that Lara has google maps installed – When Lara opens the app and selects Commute – Then Lara should see an option to find the midpoint between two locations Acceptance Criteria/Done Definition: – Midpoint is visible after user selects Commute on the Google Maps homepage Priority: High |
Task: – Create Midpoint button within Commute Acceptance Criteria/Done Definition: – The Commute page has a visible Midpoint bar with a short description and an action button |
Epic2: Allow a user to select 2 starting locations and calculate Midpoint
User Story: Show user search fields that accept two locations as input to find the midpoint – Given that Lara has selected Midpoint – When Lara clicks on the action icon, – Then Lara should see 2 search fields that accept entries in Location_A and Location_B Acceptance Criteria/Done Definition: – There are 2 search bars that take locations as inputs Priority: High |
Task: – Create 2 fields for location inputted as texts, coordinates, pins Acceptance Criteria/Done Definition: – There are 2 fields that allow a user to enter 2 locations similar to existing search bar in google maps – The fields should be smart enough to auto-fill as necessary |
User Story: Provide up to 3 midpoint options as results after entering 2 locations – Given that Lara has entered 2 locations for which she wants the midpoint – When Lara selects the action icon or hits enter – Then Lara shall be given 3 locations as options, each within 3 miles of the starting locations Acceptance Criteria/Done Definition: – 3 recommended locations, each within 3 mile of calculated Midpoint |
Task: – Develop algorithm to calculate a Midpoint between 2 given locations Acceptance Criteria/Done Definition: – Midpoint should closely match result from doing this individually in multiple sessions in Google Maps, Apple Maps, Yahoo Maps i.e. a user enters two locations in google maps as it exists today and figures out a few options in-between both starting points |
Task: – Calculate 3 midpoints within +/- 3 miles of the given locations |
Task: – Reveal these 3 calculated midpoints to the user after the Midpoint action is selected |
Epic3: Allow a user to choose category of meeting places
User Story: Recommend closest midpoint option based on user preference – Given that Lara has entered 2 starting points and selected her preferred types/category of place as coffee shops – When Lara searches for Midpoint between addresses A and B – Then Lara should only see the closest coffee shops as recommended midpoints Acceptance Criteria/Done Definition: – User can enter starting locations as well as select multiple checkboxes of types and category of places within the same page – If there are no recommended midpoints of user-selected types/category, then an error message such as “No coffee shops available as midpoint” should be displayed. The next closest coffee shop should be recommended to the user Priority: Medium |
Notice that for some of the user stories, I included brief tasks descriptions. Typically, this is something that the Engineering lead should do in-depth. However, I sometimes jump ahead and put a quick one-liner down for visibility in the backlog. During grooming, the engineering lead or engineer assigned to the task will add more information.
I actually don’t think every feature needs to be broken down into:
Epic -> Stories -> Tasks/Sub-tasks
I’ve worked on teams that used the above rigidly including some additional categories like Bugs, Themes. I’ve also worked on teams that used a sub-set and different variation. On hardware teams I’ve worked on, tasks and bugs were used almost exclusively as hardware product development doesn’t typically follow the agile methodology.
Regardless of what is used, it is important to not get bogged down and instead use an agreed-upon process that everyone on your team will adhere to. Once you agree on a process flow, it is important to be consistent its implementation but also open to making changes as needed.
Liked the post and think someone else will? Please share 😃
Share this:
- Click to share on LinkedIn (Opens in new window)
- Click to share on Facebook (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Pocket (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Click to print (Opens in new window)
- Click to share on WhatsApp (Opens in new window)
2 responses to “All Epic Stories Need Tasks…”
Awesome article, strike to the point, thanks for sharing
Thank you for reading it and for leaving a comment 🙂