What is the difference between an epic and a theme? What is a story? Is a task testable in its own right? Can you work on an epic in a sprint?
The opening session of the London Agile Discussion Group (LADG) looked at these basic terms to see if there was an agreed understanding. We were all pretty close to an agreement, but there were some interesting ideas too. Here’s a summary of what we came up with (along with my examples):
Stories
(aka Product Backlog Item, Work Item)
A story is an individual feature or requirement that the client (and business) wants. It is something that is deliverable (i.e. production ready) within a single sprint. A story should use the INVEST acronym (covered in this previous blog post).
However, it was also thought that a story is only a starting point for a discussion; it does not have all the information the team may need to complete the job.
Stories are often written in a specific format:
- As a [end user of the required feature]
- I want [actual thing the user wants to be able to do once the feature is live – so often contains a verb]
- So that [why they want this feature / the benefit this feature brings]
Although this format has caught on and is commonplace, it is not the only approach. One team stressed that they alter the above format to put the “So that …” first. I think this is a smart idea as everything should be done for a valid business reason: starting with explaining the benefit certainly makes sense to me.
An example story: “As a customer, I want to be able to save a product in my wishlist so that I can view it again later.”
Epics
An epic is a big story. A requirement that is just too big to deliver in a single sprint. Epics need to be broken into smaller deliverables (stories). This helps them support the agile principles (e.g. delivering working software frequently, early continuous delivery, regular reflection).
An example epic: “As a customer, I want to be able to have wishlists so that I can come back to buy products later.”
Themes
A collection of stories by category. A basket or bucket of stories. By its nature, an epic can also be a theme in itself.
However, interestingly, one group thought that themes should refer to business goals. My view is that everything should have a goal (otherwise why are you doing it?!)
An example theme: “Wishlist”.
Tasks
The elements of a story. Stepping stones to take the story to ‘Done’. Tasks often follow the SMART acronym: specific, measurable, achievable, relevant, time-boxed (although what the letters stand for seems to be hotly debated).
However, many teams don’t break their stories down into tasks. I have found that splitting stories into tasks encourages teams to split work horizontally, whereas we try to slice work vertically.
An example task: “Put ‘Add to wishlist’ button on each product page.”
OUT NOW!
The Innovation Revelation: A story about how to satisfy customer needs.
A real-world guide to taking a customer-focused approach to creating products and services that people actually want and are happy to pay for.
I’ve recently wrote a blog post about breaking epics to user stories and breaking them into tasks. It covers their difference, scope and the meaning of “definition of done”. Take a look – it maybe helpfull.
http://dennis-nerush.blogspot.co.il/2016/07/estimations-in-agile-development-epics.html
What is diff Between Theme and Product Backlog
Personally, I’d say that the Product Backlog is a list of ALL items that have not yet been done, whereas a theme is a collection of epics/stories (within the product backlog) that relate to one another. Now, it might be that all the remaining items in the product backlog relate to the same theme, but that’s not always the case.
What do you think?
Your explanation is very good for anyone to understand. I appreciate your work.
Thanks for this. These are controversial terms and this presents one clear definition of this heirarchy.
One thought though…
“As a customer, I want to be able to save a product in my wishlist, so that I can view it again later”
Could one really say that this story is valuable? I agree it is independent, but cannot really see what value i would get by just saving a product in the wishlist – if i cannot then view it or interact with it in another way.
Hi there,
I was wondering of these topics can be practically applied to a Kanban board as opposed to a scrum board? How do you visually represent Themes and Epics on a Kanban board?
Surely themes and epics can’t feature in the WIP columns as they are made up of tasks/stories which would be the parts to move across the board? I’m just trying to get my head around Themes, Epics and Stories and how they would translate into a visual board or would they just sit above the board itself as broader goals?
Thanks,
Hi Catherine. A Kanban Method work item would normally be something that gives some sort of new ability to a user, so it would normally be at the story level. If you wanted to identify which theme/epic a work item belongs to, maybe you could visualise that by colour-coding it (eg blue dot for wish list work items). I’d certainly not encourage teams to have work items at the task level because that does foster teamwork and doesn’t deliver any value to a user (eg having just the database layer built). Does that answer the question? Would that work for you?
Hi, nice post. We have created a nice cheat sheet on a similar Topic if it helps. http://bad.tools/rrpd/docs/cheatsheet-A0-JIT-anaysis.pdf
Enjoy!
I find it helpful to compare scrum/kanban to traditional project management using work breakdown structure (wbs).
Traditional wbs…
– project: renovate kitchen
– Phase: purchase new appliances
– Workpackage: purchase new oven
– Task: review ovens
Scrum/kanban…
– Theme: renovate kitchen
– epic: purchase appliances
– user story: purchase new oven
– task: review ovens
Both have a lot in common…
– A workpackage/user story is around 8hrs work (no more than 40hrs)
– Traditional PM has weekly meetings…scrum, kanban has sprint review, or replenishing. Basically someone making sure everything is on track.
Both have acceptance criteria (yes or no)…scrum has definition of done for a feature…traditional pm has success criteria for a deliverable.
Basically the same, just wrapped up differently.
I like to keep it simple…
What/why/how/when
-What are we doing?
-Why are we doing it?
-How will we do it? The steps (to do column in kanban)
-When is it due?
Monitor weekly.
Covers 99% of projects.
Hope this helps.
This is very much appreciated
Nice article, thank you. If you want to learn even more about epics and how to use them, check this article out: https://kanbantool.com/blog/how-to-manage-agile-epics-in-kanban-tool