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.
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.