How are user stories, epics, and tasks different from one another?
Welcome to part 59 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
Something I would like to address from the outset is that you don’t need to create or use user stories in Scrum. There are a lot of agile purists and people who are in love with agile dogma that will insist you must do such things, but it isn’t important nor MUST you do this to be successful.
The scrum guide doesn’t speak to user stories at all, it refers to the need for a product backlog item but doesn’t prescribe user stories or insist on them or epics in any way.
The concept of a user story is that you have described or articulated a need for a specific item, in the context of why this item is important, how it will solve a user problem, and/or how it will create value for both the customer as well as the organization.
So often, people become fixated on this element and think that it is best practice for scrum and must be followed to the letter. No, it’s a good practice, but one of several good practices that you can follow to achieve the same outcome.
The most widely used format for a user story is a card that says:
- As a … (insert end user or customer role)
- I want … (insert need or requirement)
- So that … (insert purpose of item)
User Story Example:
As a marketing manager, I want a comprehensive analytics tracking dashboard, so that I can quickly and easily identify opportunities, threats, and provide my boss with a visual scorecard of how we are performing against target goals and objectives.
Boom. Concise, simple, and effective.
I can’t stress this enough, but a user story doesn’t include the most comprehensive information about what is needed. What is written is not the game changer, it is a placeholder for a conversation with a customer or product owner that is important.
You are noting the essentials so that we can have a discussion about what is important, why that matters, and what the customer wish list might look like.
In the army they have a phrase, ‘the map is not the territory’, and this is very much the same.
The user story is not the territory. It simply provides a visual cue for the territory, but to understand the territory, we really need to talk to the people who know that territory inside out.
If you do choose to work with user stories, you are going to hear the word ‘epic’ being thrown about a bit so let’s deal with that. SAFe or Scaled Agile Frameworks really butchered this concept, which I won’t go into in this video, so ignore anything you may have read regarding SAFe epics.
An epic is a large story or concept.
It’s likely a concept too large to put into production without breaking it down into smaller and simpler components. It’s a placeholder for a big vision the organization have for the product or feature, and it invites discussion and refinement from everyone on the team.
It invites discussion and collaboration with customers and stakeholders and senior leaders within the organization because we understand what they want to achieve, but need to understand why it’s so important, and then follow that up by refining how we care going to make that epic a reality.
That’s where product backlog refinement sessions will play an important role in helping transform the epic into a series of smaller, more manageable items of work that could be presented in the form of user stories.
So, an epic is simply an incredibly large user story.
Tasks are what it says on the tin.
A series of things that you need to do to achieve an outcome.
Our user story may describe the need for a marketing analytics dashboard, but one of the tasks associated with doing that well would be to interview people. The marketing manager, their direct reports, and the people that they report to.
It’s an incredibly important part of designing and producing a great marketing analytics dashboard but it doesn’t require a user story for us to get it done. It’s a part of the requirements on the user story but isn’t a user story nor is it an epic.
It’s a task.
Installing Google Analytics on the company website would be another task. Creating triggers in Google Tag Manager would be another task. Setting up custom events in Google Tag Manager would be another task.
So, tasks are the things you need to do to progress from point A to point B in your product development environment. In some cases, these would be criteria in a definition of done, or they may simply be tasks that are assigned to people who are best positioned to execute.
So, that is a quick overview of the difference between user stories, epics, and tasks.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster