We spend a lot of our days talking about epics, stories, and tasks, and in many cases, we assume others understand these concepts as expertly as we do. Sometimes they don’t, and today I intend to take Leonardo da Vinci’s advice:
Simplicity is the ultimate sophistication.
Below you’ll find a table that boils epics, stories, and tasks to their most primitive forms, and it comes at a risk. Some may read this blog post and wish to prescribe these definitions on their teams. They shouldn’t. Others might argue details suggesting that one thing should be another. Today is for simplicity; details are for another day. For example, I write below that tasks should be no more than 8 hours, but what I don’t write about is the nuance:
- Tasks are for the team to find what works best for them.
- Tasks that are less than eight hours allow for team members to touch and advance a task every day.
- Such tasks also make impediments easier to spot when they’re not verbalized.
- Some teams choose not to decompose stories into tasks. That’s okay.
My point is that your mileage may vary, and as long as we clearly understand why we do what we do, then that’s what matters most. So without further ado, here’s how I simply define epics, stories, and tasks.
As extra credit, feel free to also read about spikes and how they apply to agile teams.
| Type | Definition | Attributes |
|---|---|---|
| Epic | A large user story that drives toward a single business objective |
|
| Story | A piece of work that creates value for the customer and that usually takes more than one team member to complete |
|
| Task | An action item usually for a single team member and sometimes called a sub-task |
|
Do you want to get notified when new posts are published? Leave your email below.
Typo i think:
“Tasks are for the team so find what works best for them.”
was probably supposed to be:
Tasks are for the team to find what works best for them.
I’ve found that no amount of proofreading ever finds them all. Fixed. Thank you.