All Epic Stories Need Tasks…

Reading Time: 5 minutes

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.

Epics, Stories and Tasks for Agile Product Development

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:
  • 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 😃



2 responses to “All Epic Stories Need Tasks…”

  1. Prediksi Bola dan Togel Paling Jitu Avatar

    Awesome article, strike to the point, thanks for sharing

    1. Author Avatar
      Author

      Thank you for reading it and for leaving a comment 🙂

About Laide

Hi, I’m Laide. I’m currently a founder. Previously engineer & product manager

Featured Posts