Skip to content

Work Tracking

Understanding Agile Work Hierarchy: Stories, Epics, and Initiatives

In distributed teams, having a shared understanding of Agile terminology is essential to working effectively. This post explains the hierarchy of Agile work items and how they fit together to support clarity, alignment, and execution.

🧩 Work Item Hierarchy Overview

graph TD
    %% the preview is rendering the bottom
    %% subgraph first, so switching them here
    subgraph Initiative 2
        I2E1[Epic]
        I2E2[Epic]
        I2S1["Story: 'What?' & 'Why?'"]
        I2S2["Story: 'What?' & 'Why?'"]
        I2T1["Task: 'How?'"]
        I2T2["Task: 'How?'"]
        I2T3["Task: 'How?'"]
        I2T4["Task: 'How?'"]
        I2E1 --> I2S1
        I2E2 --> I2S2
        I2S1 --> I2T1
        I2S1 --> I2T2
        I2S2 --> I2T3
        I2S2 --> I2T4
    end

    subgraph Initiative 1
        I1E1[Epic]
        I1E2[Epic]
        I1S1["Story: 'What?' & 'Why?'"]
        I1S2["Story: 'What?' & 'Why?'"]
        I1T1["Task: 'How?'"]
        I1T2["Task: 'How?'"]
        I1T3["Task: 'How?'"]
        I1T4["Task: 'How?'"]
        I1E1 --> I1S1
        I1E2 --> I1S2
        I1S1 --> I1T1
        I1S1 --> I1T2
        I1S2 --> I1T3
        I1S2 --> I1T4
    end

    Initiative1[Initiative 1] --> I1E1
    Initiative1 --> I1E2
    Initiative2[Initiative 2] --> I2E1
    Initiative2 --> I2E2

📝 Definitions

Level Description
🧱 Task The "how?" – implementation-level steps proving stories are fulfilled.
📗 Story The "what?" and "why?" – user-centric requirements with criteria.
📘 Epic A collection of related stories forming a larger feature.
🗂 Initiative Strategic objective spanning multiple epics.

Quick Analogy:

Stories = Requirements. Tasks = Implementation.

🌍 Why It Matters for Distributed Teams

  • ✍️ Shared Vocabulary: Avoids confusion across locations.
  • 🎯 Goal Alignment: Connects daily work to strategic initiatives.
  • 🔍 Traceability: Tasks trace back to story requirements.

For a deeper, evolving reference guide, see the Agile Work Hierarchy Reference page.

Agile Story vs Task

Note

This is meant to be way to help understand and develop a process for tracking work in a distributed team.

Agile Story vs Task

In Agile frameworks like Scrumban, understanding the distinction between a task and a story is crucial for effective project management. A user story is typically functionality that will be visible to end users and captures requirements and acceptance criteria from the user's perspective. Developing a user story usually involves multiple roles such as a programmer, tester, user interface designer, or analyst, indicating that it contains multiple types of work. 03

On the other hand, a task is a unit of work that is generally worked on by one person and is restricted to a single type of work. Tasks are implementation activities designed to prove that the requirements and acceptance criteria of user stories have been met. They are often technical in nature, such as implementing a class, setting up a virtual machine, writing a script, or conducting UI testing. 02

In the context of Jira, a popular tool for Agile project management, a Story is a more specific version of a Task. Both are work requests, but a Story was created to help people tracking User Stories in Jira. Tasks in Jira are considered "units" of work and are often used for activities that are not testable, whereas stories are for functionalities that can be tested and potentially shipped. 04

Scrumban, a hybrid of Scrum and Kanban, utilizes both concepts but emphasizes visualizing work, limiting work in progress, and maximizing efficiency. In Scrumban, tasks are represented as cards on a Kanban board, moving through different stages of the process, while stories are part of the product backlog and are prioritized based on complexity and product demand. 07

The key to distinguishing between a story and a task lies in understanding that stories bring functionality and value that is recognizable to the user, while tasks are the steps taken by developers to realize that functionality. 02 This distinction helps in organizing work in a way that aligns with both the user's needs and the team's capacity to deliver. 08

Work tracking in a distributed team

Note

This is meant to be a visual overview of how to manage issues as part of an overall work tracking process.

As mentioned in the Using Scrumban in a distributed team post, using Sprints to plan and define the work that will be completed can be extremely helpful in a distributed team. There should be a formally established process to follow in order to help everyone understand expectations. In this scenario, we can find out how we can use GitHub issues to plan and track work which can be helpful given the recent changes the GitHub team is making to issues and projects.

Agile Project Management Terminology

What are stories, epics, and initiatives? (from atlassian.com)

  • Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.
  • Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
  • Initiatives are collections of epics that drive toward a common goal.
flowchart TD
    %% the preview is rendering the bottom
    %% subgraph first, so switching them here
    subgraph Initiative 2
        I2E1[Epic C]
        I2E2[Epic D]
        I2S1[Story C1]
        I2S2[Story D1]
        I2E1 --> I2S1
        I2E2 --> I2S2
    end

    subgraph Initiative 1
        I1E1[Epic A]
        I1E2[Epic B]
        I1S1[Story A1]
        I1S2[Story B1]
        I1E1 --> I1S1
        I1E2 --> I1S2
    end

    Initiative1[Initiative 1] --> I1E1
    Initiative1 --> I1E2
    Initiative2[Initiative 2] --> I2E1
    Initiative2 --> I2E2

Including Tasks to use with GitHub Projects

We can build on the Agile project management terminology by adding tasks as a subset of either a story or an epic. The differences are explained more in the Agile Story vs Task post and the Understanding Agile Work Hierarchy post.

For a deeper, evolving reference guide, see the Agile Work Hierarchy Reference page.

Using Scrumban in a distributed team

Note

While this document is not in draft mode it is definitely not complete...

Being flexible and efficient can make working in a distributed team a great experience; sometimes though, you have to be the agent of change to help your team get there. While trying to understand what Scrumban actually is, it seemed best to type it up myself to reinforce what I have learned so far.

Scrumban combines two leading Agile methodologies—Scrum and Kanban—into a single process for getting work done. But what is scrumban? And why should you consider its unique approach?

These are notes based on the following resources:

What is Scrumban?

The Scrumban methodology combines the best features of Scrum and Kanban into a hybrid project management framework. It uses Scrum's stable structure of sprints, standups, and retrospectives. Then it adds Kanban's visual workflow and work-in-progress limitations. The result is a truly flexible method for managing projects of any size.

Agile Ceremonies

An Agile ceremony is an event in the Agile process when your team meets to discuss what their next course of action is.

There are four major Agile ceremonies that happen during every sprint cycle. Before starting each ceremony, your team members should understand the purpose of each meeting and how it impacts the sprint.

The 4 Agile ceremonies

  1. The sprint planning meeting
  2. The daily stand-up meeting
  3. The sprint review meeting
  4. The sprint retrospective meeting

Intentionally timely

Timeboxed meetings

As mentioned in the stand-up meeting wikipedia page, the stand-up meetings are intentionally timeboxed:

The meetings are usually timeboxed to between 5 and 15 minutes, and take place with participants standing up to remind people to keep the meeting short and to-the-point.6

Keep the meeting short

The daily stand-up meeting (also known as a “daily scrum”, a “daily huddle”, “morning roll-call”, etc.) is simple to describe:

The whole team meets every day for a quick status update. We stand up to keep the meeting short.

That's it.

But this short definition does not really tell you the subtle details that distinguish an effective stand-up from a waste of time.

So how can you tell?

The answer to the question of an effective stand-up is addressed in the It's Not Just Standing Up: Patterns for Daily Standup Meetings article, which is linked from the stand-up meeting wikipedia page.

The Kanban board

GitHub projects offers one way to use a Kanban board, this is accomplished using custom views in your GitHub project, specifically the board layout, which is based on the status field.

Example status field settings

Here is an example of Status field settings for a GitHub project:

  • Triage: Items to be triaged
  • To do: Triaged items up for grabs. Please choose based on determined priorities.
  • In Progress: Items actively being worked on
  • Review Needed: PRs and issues that require review
  • Changes Requested: Reviewed PRs and issues with changes requested
  • Approved: Approved PRs that need to be merged, or approved items that need to be completed
  • Done: Items that have been completed

Here is what that would look like in the Status field settings page:

github-project-status-field-settings

Using GitHub project workflows to improve timeliness

Note

This section is incomplete and should be in a separate blog post. It is "to be continued"...