Product Backlog and Backlog Grooming in Scrum Options

codeling 1217 - 5163
@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 1217 - 5163
@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. 


codeling 1217 - 5163
@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 1217 - 5163
@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