Product Backlog and Backlog Grooming in Scrum Options

codeling 1264 - 5397
@2019-03-28 13:57:45

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:

  • Description: What the goal of the PBI is.
  • Value: the Business Value of the PBI as determined by the Product Owner.
  • Estimate: the Team needs to estimate the relative effort it will take to move the PBI to Done.
  • Order: The Product Owner needs to prioritize PBIs by their relative value.

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:

  1. User Stories
  2. Defects
  3. Technical Work
  4. Knowledge Acquisition

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. 

Technical work and knowledge acquisition activities also belong on the agile backlog. An example of technical work would be, "Upgrade all developers' workstations to Windows 10." An example of knowledge acquisition could be a Scrum backlog item about researching various JavaScript libraries and making a selection.

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.


codeling 1264 - 5397
@2020-01-18 00:13:28

User Story

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 somethingSo 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:

  • A user cannot submit a form without completing all the mandatory fields.
  • Information from the form is stored in the registrations database.
  • Protection against spam is working.
  • Payment can be made via credit card.
  • An acknowledgment email is sent to the user after submitting the form.

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. 

 

How is detail added to user stories?

Detail can be added to user stories in two ways:

  • By splitting a user story into multiple, smaller user stories.
  • By adding “conditions of satisfaction.”

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:

  • Make sure it works with major retail holidays: Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
  • Support holidays that span two calendar years (none span three).
  • Holiday seasons can be set from one holiday to the next (such as Thanksgiving to Christmas).
  • Holiday seasons can be set to be a number of days prior to the holiday.

 

Who writes user stories?

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.

 

When are user stories written?

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.

 

Do user stories replace a requirements document?

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.


codeling 1264 - 5397
@2020-01-18 08:54:53

Use Case

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 title
  • rationale/description/goal
  • actor/user
  • preconditions (the things that must have already happened in the system)
  • standard path or main success scenario (what will usually happen, described as a series of steps)
  • alternate paths or extensions (variations on the above/edge cases)
  • post conditions (what the system will have done by the end of the steps).

Example of Use Case

Use Case 01 — Show the current balance amount

Brife Description:

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.

Actors:

Mobile application (Primary)

Preconditions:

Login, before this use case begins the customer has logged onto the system.

Flow of Events:

Success Flow

  1. Customer has logged onto the system via mobile application.
  2. Mobile application sends request to the <XXX> to inquiry the current balance amount of the main bank account with <Parameters>.
  3. <XXX> forwards requests with parameters to ,<YYY>.
  4. <YYY> delivers the amount of the main bank account to <XXX>.
  5. <YYY> logs the transaction to Logging Service with <Parameters>
  6. <XXX> delivers the amount of the main bank account in REST format to mobile application.
  7. <XXX> logs the transaction to Logging Service with <Parameters>.
  8. Mobile application presents the current balance amount on the screen to customer.

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)

  1. Condition 1
  • Text

2. Condition 2

  • Text

Acceptance Criteria

Pass all Acceptance Test Cases

  • Refer to the acceptance test cases document <name of the document>

REST structure with data of <XXX> delivers to mobile applicaiton

  • Refer to the expected REST following the acceptance test cases <name of the document>

Non-Functional Test Exit Criteria

  • Response time must less than or equal to 2 seconds at 3,000 concurrent when mobile application presents the current balance amount on the screen to customer.
  • Response time must not over then 1 second at 3,000 concurrent when <YYY> delivers the amount of the main bank account to <XXX>.
  • Pass all loadtest scenarios following the document <name of the document>
  • Pass all stress test scenarios following the document <name of the document>
  • Pass all criteria following the check list from security team that related to the balance inquiry procedure.

Additional artifacts in the use case

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:

  1. User interface
  2. Activities diagram
  3. Flow chart

codeling 1264 - 5397
@2020-01-18 09:38:33

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:

  • removing user stories that no longer appear relevant
  • creating new user stories in response to newly discovered needs
  • re-assessing the relative priority of stories
  • assigning estimates to stories which have yet to receive one
  • correcting estimates in light of newly discovered information
  • splitting user stories which are high priority but too coarse grained to fit in an upcoming sprint
Users browsing this topic
Guest