Features, Epics, Stories, and Tasks

So let’s talk about the Matryoshka Dolls of the Scrum world. I think having an understanding – a Ubiquitous Language as it were – of what we will be using to discuss how we approach work is important, that’s why I love these process discussions as they pop up. Like in all domain modeling discussions, a Ubiquitous Language is only as useful as it has a shared understanding of the meanings of a word. Otherwise we could just choose random string when naming things. It’s the meaning of a word like Task in the domain specific context. When speaking of Scrum it means an item of work that allows me to signal to the team what precisely I’m doing while working on the story. When talking to my children it might mean the same as a chore. All things worth naming morph in meaning depending on the context.

That we choose to use a Kanban board when tracking our work is important. Understanding the context of Kanban and Agile and why we do what we do will help us understand the reasons why we do what we do and how we do it. Kanban is first and foremost a signal system. The original signal of Kanban was an empty box on a grocery shelf. When the box is empty is a signal to bring a new box out. Kanban is a demand/pull system, each process takes supply from its parent as it needs it. But it’s also a signal based system. As one “bucket” is emptied it pulls the next item from inventory.

We use work items to signal a supply of inventory to be pulled from. Team members pull from that supply and move them along the value chain but the work items are also a signal to the rest of the team. The Kanban board is an “ information radiator” that not only shows what is in flight but also what an individual is working on.

The hierarchy of work items are: Feature, Epic, Story, Task. Stories matter because that is how we measure velocity. The other work items matter because they allow us to think of the project at a larger and smaller scope than a story.

Story

We’ll start with stories because they are the central unit of work by which velocity is measured. Ideally the ratio of work should be one story per team member per sprint. I’m not saying that’s how the work will be broken down, I believe in swarming on stories as a team as much as is feasible without adding overhead in order to keep everyone “busy”. I’ll take an aside here to point out that if your goal is 100% utilization of all “resources” you’re doing it wrong.

Some stories will be small, some will be large, we need to specify them such that the story can meet the teams DoD by the end of sprint at the high end, and significant enough that it’s not just a Task. A process smell is “Developer Stories” (except when the “Developer” is the end user of the project).

“As a developer I want to create a CosmosDB account, so that I can store purchase data in it”

That’s not a User Story, that’s a task. Compare to

“As a Developer using Eventual, I want to specify CosmosDB as store for my data so that I can use it as a Sink for my EventHandler”

One is an infrastructure task that should be beneath a User Story, the other describes functionality that the Eventual framework ( shameless plug) will provide for developers who are the target users of the framework.

Task

A task is a division of labor for a User Story. Tasks should be broken down as the developer(s) working on the story sees fit. But as a guideline, they should be sized to be completed within a day or two at the longest. Why’s that?

The Daily Standup is a way for the team to take a pulse on progress. When a developer is working on a story for three days, without tasks, there is no visibility into that work. If instead that developer says at stand up,

“Yesterday I completed task X & Y. Today I’ m working on task Z. I have a blocker on task Omega because [reason delta]”

That gives a lot more insight into the work she is doing.When the developer says for the third day in a row

“Yesterday I was working on task Alpha again, today I hope to finish Alpha and move on to Beta. No blockers”

That is a signal. We should be looking for the “No blocker” that actually is a blocker and someone should say

“Hey Paul, it seems like Alpha is giving you problem, want to pair on that together?”

Epic

A story should fit within the bounds of a sprint. If it doesn’t, consider breaking it into multiple stories as part of an epic. If there are stories that have dependencies for example:

1. I can’t finish X until Y is completed
2. The complexity of Zeta will change based on if Iota is done

For a real example, I had a pair of stories, completing one meant that finishing the other would be a few lines of code. The complexity of either independent of the other would be the same, but completing one vastly simplified the complexity of the other. Both stories offered independent, observable features with their own acceptance criteria. And the benefits of both were equal. Measured independently both would get an 8 for story points, but because I knew there was a follow up story I mortgaged the effort across the two with a slight bump in complexity for the one and a massive savings in effort for the other. They could be delivered independently of each other but they were related and that’s what an Epic is for.

Feature

Features lie above epics they don’t need to have epics but they can. A feature is a grouping of stories that combined form a larger piece of functionality. A story might be > Specify a CosmosDB store for a Data Sink

The feature would be > Define Solution Infrastructure as Code

Features of course can go across sprints and even milestones (milestones allow you to set a longer term direction than individual sprint). They allow you to group work in broader categories than stories and epics.

How often to PR

That’s a team decision. My default is that I PR to the story. I make commits to the task. So even if there is a larger PR with a lot of tasks completed for it, it’s easy to break down the PR according to commit so that it’s easy to see wha ’s happening step by step. Rather than dealing with the noise of a seven to ten file PR. Some teams prefer PRs for each task so it’s broken down naturally. I say go for whichever fits your team’s style without adding too much overhead.

Those are my observations and strong opinions loosely held.