Refine Requirements to Product Backlog Item with Use Case Options

codeling Posts: 1153 Points: 4845
Posted: Thursday, March 28, 2019 1:57:45 PM

In Scrum, the product backlog is the single source of requirements that be ordered list of everything; features, stories, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. In the product backlog, the product backlog items (PBI) have the attributes of a description, order, estimate, and value:

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

User Story

By far, the predominant way for a Scrum team to express features in the 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 show my current balance amount so that I know how much I have spent.”

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.

Product Backlog items often include test descriptions that will prove its completeness when “Done.” User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and 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.

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

codeling Posts: 1153 Points: 4845
Posted: Thursday, March 28, 2019 1:58:50 PM

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.


Mobile application (Primary)


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
Users browsing this topic