This article looks to discuss Epics Stories and Tasks. This article is part 2 of an 2 section discussion on developing Epics and focusses on the Scrum Master role in the development of Epics. Part 1 is available by following this link.
Epics Stories and Tasks
A 59 Seconds Agile Training Video
Continue to Part 3 Below
Epics Stories and Tasks for Scrum Masters – Part 2
A 59 Seconds Agile Article
Epics Stories and Tasks: Epics
Epics are basically large user stories that are made up of smaller stories and aim to complete a certain user workflow. Each epic has a different goal that needs to be reached, and are too general to fully detail the work that needs to be done. Some features ideated while getting feedback from a customer may look simple at first. When these features are then planned for a Sprint and they turn out to be too big, they might actually be more appropriate to be listed as epics. It can also be suggested that when a group of five or more stories is seen to share a similar focus, an epic can be constructed to group these stories together.
Epics Stories and Tasks: Epic Example
Let’s say a Scrum Team wants to improve their product backlog management tool. They could say: “We want a burn-down chart that summarizes our progress throughout the project.”
Because they want to treat it as a backlog item, they write it in the following user format:
As a Scrum Team, we want to have a burn-down chart so that we can see our project progress.
Epics Stories and Tasks: The Objectives
While the objectives are clear, they might start asking specifics on this story, what they can do with it, and to what extent they can use this feature. They could ask things like:
1. Can I select a range of sprints for the chart to display?
2. Can I toggle between Release and Sprint burn-down charts?
In order to address these questions, they can further break these down into the following user stories:
1. As a Product Owner, I want to set the range of sprints in the Release Burn-down Chart so that we can focus on a specific set of sprints to discuss.
2. As a Product Owner, I want to have a burn-down chart that displays the progress of releases so that I present a visual of the project overview to stakeholders.
3. As a Developer, I want to see the burn-down chart of the current Sprint so that we can visualize the remaining work for the Sprint.
Epics Stories and Tasks: Decomposition
Breaking down the first user story in this section will shed light on more specific functionalities that the feature can have. It is possible that the team can further break down the user stories however they like.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Some questions that can be asked to know when a story can be split would be the following:
1. Does the story seem to be too complex for estimation?
2. Can this be finished with a Sprint?
3. What are the dependencies of this story?
4. Is there anything that is unclear in a technical or business manner?
Finding The Answers
Finding answers to questions like these can help the team decide whether the user story is actually big enough to be an epic and can be split into more user stories.
Epics are large stories that can span sprints and are made up of smaller user stories. They are placeholders for the work to be done and group functionalities by specific user work-flows. Product backlog management can be improved by working with the stakeholders on their feedback and discussing within the team on deciding how to construct epics and user stories.
Prev <— Continue Reading —> Next
Epic Scrum Requirements
A 59 Seconds Agile Video Animation
Prev <— Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
Developing Agile Epics
A 59 Seconds Agile Infographic
