User requirements in Agile Scrum

In the Scrum framework, artifacts are created for structuring information in such a way so as to maximize transparency and opportunities for the team to inspect and adapt. They help the entire team understand all the details of the product and where the development process is headed.

Scrum Artifact is composed of the following elements-

1. Product vision
2. Product roadmap
3. Product backlog
4. Sprint backlog
5. User stories, epics/features, and acceptance criteria

The major Scrum artifacts are product backlog and sprint backlog.

A product backlog is a simple method of organizing requests/user/customer requirement in the form of a list. It constitutes of requests that add value to the customers. Further, the list is categorized according to its function. For example, some requests might be regarding adding a new feature; some might be regarding fixing a bug and so on. It helps if you refine the requests into their respective categories like features, bugs, technical work and knowledge acquisition.

The definitions of epic, feature, and user story as per SAFe’s definitions are:

• User Story: “Stories are short descriptions of a small piece of desired functionality, written in the user’s language…User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.” (© Scaled Agile, Inc.)
• Feature: “A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).” ( © Scaled Agile, Inc.)
• Capability: “A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.” (© Scaled Agile, Inc.)
• Epic: “An Epic is a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval before implementation.” (© Scaled Agile, Inc.)

In other words, according to SAFe:

• An epic is “something that is almost, but not quite, entirely unlike a project.”
• A feature is what everyone else refers to as an epic,
• A user story is a type of story
• Epics can be broken down into capabilities which can be broken down into features which can be broken down into user stories.

To be fair, the SAFe requirements model has these different levels of hierarchy because SAFe also has multiple backlogs. Each backlog contains a different type of backlog item:

• Portfolio backlog: “The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.” (© Scaled Agile, Inc.)
• Solution backlog: “The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.”(© Scaled Agile, Inc.)
• Program backlog: “The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.”(© Scaled Agile, Inc.)
• Team backlog: “The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.”(© Scaled Agile, Inc.)

It might be possible that your product is so big that you may need multiple teams working on it, and you may want to organize those teams into multiple teams of teams.

Even if you do find yourself in that situation, experience has shown me that you don’t need four separate backlogs with four separate levels of hierarchy to coordinate the efforts of over 90 teams split across multiple locations. A two level hierarchy and some good old fashion communication can work wonders!

Product Backlog items

Epic/Feature, Bugs/Fixes, Technical work, Knowledge Acquisition

Let’s take an example of of PBIs of redBus Portal. redBus is an Indian online bus ticketing platform, providing ticket booking facility through its website, iOS and Android mobile apps.

PBI for Offerings Page of redBus

The product backlog is in the form of user stories. Whether it is a feature, bug/defect fix, Technical work or Knowledge Acquisition

Ex. Feature of redBus Offerings page-

Ex. Bug/defect fix

Ex. Technical work

Ex. Knowledge Acquisition

User story —

One of the key things about a product backlog is it is not a static document. It’s a live document. In fact, it keeps changing. If not on a daily basis, I would say at least on a weekly basis. As long as the product is alive, we want the product backlog to keep changing and it should reflect the current realities of the product.

Writing a Feature/Epic

Writing an Epic/Feature is one of the most basic and most important task of a Product Manager. A well written epic is a key to have good understanding and material to refer in case of any doubt during dev process across org. It is referred by dev team, sales team, and executive team.

Elements of Epic/feature -

Example of an Epic/feature

Product Requirement

UX design Requirement

Engineering Requirement

Acceptance Criteria

• User stories are placeholders for the requirements the product owner wants to incorporate into the product
• They are written in a high-level format and the details emerge from discussions between the product owner and the rest of the team
• It initiates a conversation between the product owner and the team
• Epics/features are bigger stories in the product backlog.
• These are coarse-grained requirements
• They usually cannot be accomplished in one sprint
• An epic needs to be broken down into smaller stories

One of the formats for a user story is: ‘As a user, I would like to ___ so that I can ___.’

• As a user: This gives you the category of the user to which the user story applies
• I would like to ___: This is the intended action which is translated into the requirement
• So that I can ___: This articulates the benefit behind the story so that the purpose is clear and explicit to the team

The three Cs of the user story are:

• Card: A small card on which the user story is expressed in a high-level format
• Conversation: A user story is a placeholder for conversation between the product owner and the team
• Confirmation: Acceptance criteria are written for the team to understand the conditions of satisfaction

A criterion to assess users stories is I.N.V.E.S.T.

• Independent: User stories should be independent as any dependency would make it difficult to prioritise them one over the other
• Negotiable: The implementation details are not specified and are left to the team
• Valuable: User stories should have value to the customers
• Estimable: They should be broken down into the simplest form that the team can work with
• Small: They should be small enough to be finished within a sprint
• Testable: The incremental deliverable should be testable against the acceptance criteria specified

If user stories are too large, they are vertically sliced down into smaller ones. Each of these should be an end-user-facing functionality. The team can them stagger these stories into the sprints. Acceptance criteria help the product owner assess if he/she should accept a particular user story.