This article looks to discuss the role of the Scrum Master in Developing Stories and Epics, along with the Scrum Master Persona. The article covers how to collect content for the Product Backlog and how to break down the Backlog Items.
The History of Agile
A 59 Seconds Agile Video Animation
Stories and Epics: Developing Epics for Scrum Masters
The term ‘epic’ in agile practices refers to a large user story. This is a story that has not yet been defined in detail (An Epic is a large User story). Typically, an epic will cover a single business process. This user story must be fully completed as a whole for the business value to be realized. These user stories are described as epics because they will require refining over multiple cycles before they can be considered done.
Defining epics and scheduling them into a release plan is an effective way to manage the product backlog. Part of identifying what epics can be made for the project requires an understanding of the granularity of backlog items. Scrum Masters can help the Product Owner and the Development Team (software developers) in defining and planning of Epics. They can do this by letting them understand what epics are. They can help the team understand how they can be broken down into user stories.
Stories and Epics: Collecting Content for the Product Backlog
The product backlog consists of requirements that come from conversing with the stakeholders. Some ways that can be used to collect such content could be the following:
1. Workshops – Meetings and sessions where the Agile Team empathizes with a group of customers and users by having them present problem areas and solutions to each other. This can be done by writing them down on post-its, grouping them together, and later on processing next steps.
2. Interviews – Up close conversations with individuals that have more personal statements, which can lead to useful and unique insights for the product.
3. Questionnaires – Surveys that are accessible to various users and customers and can be answered at their own convenience. Results can be more quantitative in nature since trends and patterns can be found based on the answers.
Scrum Master Personas: Collecting Content for the Product Backlog
Analyzing results from workshops, interviews, and questionnaires will help the team come up with User Personas who represent user groups for the product. Designing the product around User Personas helps ensure that the developed product is valuable by addressing the problems and preferences raised by users.
Stories and Epics: Breaking Down the Product Backlog
One could think of the product backlog as a large repository of work that can be divided into smaller and smaller parts. There’s the overarching statement of what the product is, broken down into what its objectives are, and then further split into what functionalities it has.
The granularity of a feature will vary from one organization to the other. Some organizations use themes or value streams to group features together. Some organizations come up with epics that cover different focus areas, and then map smaller user stories that complete these epics. The Scrum team and the stakeholders need to work together on deciding how to categorize user stories into epics and epics into themes.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Stories and Epics: User Stories
User stories note the agreements between the stakeholders and the Scrum team and detail what actions need to take place within the product. A popular template used for writing user stories are:
As a (type of user), I want to (action here) so that (reason or intended output here).
This statement encapsulates what the Scrum team needs to cover when developing the product: who the user is, what they want to do, and why they want to do it, as well as the value it will give to them.
Stories and Epics: INVEST Criteria
The INVEST criteria guides Scrum teams into coming up with good user stories, and it stands for the following:
Independent – Story is not redundant and provides enough detail as it is.
Negotiable – Story can be discussed and is eventually negotiated.
Valuable – Story is important to the customer.
Estimable – Story has an approximate range along which it can be estimated. Team estimates should be possible.
Small – Story fits within an iteration.
Testable – Story is clear enough to be tested.
Following the INVEST criteria helps the team practice exchanging feedback, estimating effort, and implementing features with sufficient understanding.
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
