Product Backlog and Backlog Grooming in Scrum
In Scrum, the product backlog is is a prioritized list of product backlog items (PBIs) which could be features, epics, user stories, enhancements, bugs or time-boxed technical tasks. Each product backlog item (PBI) must have these attributes:
Not all product backlog items in the product backlog will be of the same size and level of detail at the same time. PBIs that we plan to work on soon should be near the top of the backlog, small in size, and very detailed so that they can be worked on in a near-term sprint. PBIs that we won’t work on for some time should be toward the bottom of the backlog, larger in size, and less detailed.
For the purpose of simplicity, the product backlog can be grouped into four types of items:
User stories cover features, enhancements, and epics. By far, the predominant way for a Scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user. An example would be, "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected."
Because there's really no difference between a bug and a new feature -- each describes something different that a user wants -- bugs are also put on the Scrum product backlog.
Normally the product owner is primarily responsible for creating the product backlog on behalf of the stakeholders, but it is not necessary for a product to create every backlog items. Typically the product owner might create large PBIs according to the high level requirement or user goals, the team will then help the product owner to break down the large items into user stories as it move to the top of the backlog as some “sprintable” user stories.
Also the product owner is responsible for maintaining the product backlog. The key activities in maintaining the product backlog include prioritizing product backlog items, deciding which product backlog items should be removed from the product backlog, and facilitating product backlog refinement.
As mentioned above, User stories are short, simple descriptions of the desired functionality told from perspective of the user and always be written in the format: As a Type of User, I Want to do something, So that why do I want it.
Unlike the traditional requirement capturing, User Story focuses on what the user needs instead of what the system should deliver. This leaves room for further discussion of solutions and the result of a system that can really fit into the customers' business workflow, solving their operational problems and most importantly adding value to the organization.
User stories aren’t just single sentence affairs, they are not complete without Acceptance Criteria. The acceptance criteria, which define the boundaries of a user story, are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:
Writing the acceptance criteria is the first step of fleshing out the details of your user story.
User stories cover features, functions, enhancements, and epics. a large user story has been refined to an appropriate level of detail with estimates and acceptance criteria so that they can be worked on in a near-term sprint. As we get closer to working on a larger PBI, such as an epic, we will break that story down into a collection of smaller, sprint-ready stories during the backlog grooming. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week.
Detail can be added to user stories in two ways:
When a relatively large story is split into multiple, smaller agile user stories, it is natural to assume that detail has been added. After all, more has been written.
The conditions of satisfaction is simply a high-level acceptance test that will be true after the agile user story is complete. Consider the following as another agile user story example:
As a vice president of marketing, I want to select a holiday season to be used when reviewing the performance of past advertising campaigns so that I can identify profitable ones.
Detail could be added to that user story example by adding the following conditions of satisfaction:
Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member.
Also, note that who writes a user story is far less important than who is involved in the discussions of it.
User stories are written throughout the agile project. Usually a story-writing workshop is held near the start of the agile project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.
Some of these agile user stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone.
Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog items.
While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.
It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.
Use Case can be used to refine product backlog items since Use Cases are used to capture user (actor) point of view while describing functional requirements of the system. They describe the step by step process a user goes through to complete that goal using a software system.
A Use Case is a description of all the ways an end-user wants to "use" a system. Use Cases capture all the possible ways the user and system can interact that result in the user achieving the goal. They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.
A use case is usually created as documents, and generally include this kind of information:
Use Case 01 — Show the current balance amount
This use case allows a mobile application to inquiry the current balance amount in THB of each account and shown on the first screen of the mobile application.
Mobile application (Primary)
Login, before this use case begins the customer has logged onto the system.
Flow of Events:
Alternative Flows (Note alternative flows can be splited to be the Use Case in case of development team cannot deliver both success flow and alternative flows in the Sprint)
2. Condition 2
Pass all Acceptance Test Cases
REST structure with data of <XXX> delivers to mobile applicaiton
Non-Functional Test Exit Criteria
For each use case following the example above is not enough you must have the additional artifacts with it, too. In example the list below:
Backlog refinement (formerly known as backlog grooming) is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity. Some of the activities that occur during this refinement of the backlog include:
© 2020 Digcode.com. All rights reserved.