I was working with a client this last week and I overheard one team member trying to explain the difference between Epics, User Stories, and Tasks. He finally offered an analogy.
The Analogy
Epics are to User Stories are to Tasks as Rocks are to Pebbles are to Sand.
I thought it was a clever description of comparing relative size and complexity of work. But would it pass muster with the Agile Community? I figured I would send it out to the Twitter-verse and see if any conversations would result.
The result was an excellent conversation with David Koontz.
The Conversation
Though I will admit there are some challenges in communicating in 140 characters or less, it really forced me to think about what I was trying to say. David did a really great job of challenging me to explain what I was thinking. In tweet responses, David stated if it can fit in a Sprint, he calls it a User Story. If it is too big to fit in a Sprint, it is called an Epic. I have to say, if we all followed that model, it certainly would simplify things.
I find customers asking if they can call them sub-stories, major stories, and craziness like that. Customers take a stab at breaking down work to manageable chunks but when the team estimates the work, it's still too big to fit into a sprint. To restate David's identifying criteria, too big equals epic; small enough equals user story.
David then asked me,
does Epic == collection of stories? Or some stories and some waste we should never do?
My response was,
The Clarification
To clarify my beliefs, I believe a User Story as merely a placeholder for a conversation. I believe an Epic is a placeholder for a goal or an idea. Along the way, there will be resulting value delivered and waste.
Though you should be able to map all of your User Stories (and waste) back to Epics, that's not the goal. You don't just do tasks and then look for a bucket of stories or epics to group your efforts.
I won't say having something small enough to fit in a Sprint is automatically called a User Story. What if you don't leverage Scrum? What if you are leveraging Kanban? In either case, we refer back to the conversations. As long as your work meets your definition of Ready, I don't care what you call it.
Thank you, David, for an excellent conversation. I hope others will join in.