Refine Product Backlog

(Activity) for Tier: Sprint

PURPOSE

Backlog refinement is an ongoing collaborative effort led by product management and includes significant participation from internal and external stakeholders as well as representatives of the development team. Backlog refinement provides insight toward the delivery of desired product features within an estimable timeframe of release, as well as an opportunity to refine a need through clarification activities. In addition, backlog refinement provides the project team a backlog of ready work that can be selected for sprint work.

WHEN

Ongoing collaborative effort.

ENTRY CRITERIA

  • Criteria for refined User Stories or Bugs have been defined by the team

SUB-ACTIVITIES

  1. Establish Cadence

    • Scrum Master , coordinating with the Product Owner (PO), and Development Team identifies and facilitates a product backlog refinement cadence. The Scrum Master typically facilitates this meeting, while the Product Owner ensures success of the overall flow of requirements development.
    • The team identifies representatives (i.e. Developer, Tester, User Experience (UX) Architect) to participate in product backlog refinement activities.

  2. Refine User Stories

    • The PO and team collaborate to achieve a shared understanding of the value of the user story, its meaning, and what part it plays in the parent feature.

    • The team reviews each user story to ensure a shared understanding and that it meets the INVEST criteria, then marks the item as “refined”, per the team’s procedures. Record discussions and notes about the user story within the work item.

      • (I)ndependent: The team ensures the user story can be independently developed. Not all stories can be entirely independent so the team will document risks and manage dependencies when applicable.
      • (N)egotiable: The team ensures the user story is negotiable. Some aspects of the user story may be decided just-in-time and aren’t beholden contractional specification. This is common for UI “look and feel.”
      • (V)aluable: The team ensures the user story produces value to the customer/user. Each user story should have a value statement that clearly indicates its purpose. User stories should be “vertically” sliced (cross tiers) when at all possible, rather than horizontally sliced (per architectural layer).
      • (E)stimable: The team ensures the user story is estimable through their shared understanding of the story, business domain, and system knowledge.
      • (S)mall: The team collaborates on user story sizing by allowing each relevant team member to contribute their estimation and discuss how they determined it. The team should use relative estimation “This thing will take about as long as that thing”. The goal is to write them so they are “small.” Small means it can be completed within a single sprint. The team may accept larger stories with Mitigation Plans.
      • (T)estable: The team ensures the user story is testable.

      Note

      The process guidance does not define how to mark work items as refined. Team Procedures are to document how work items are marked as refined. Effective examples include tags or board columns. Recording items as refined on a paper notepad stored in the Product Owner’s office is an ineffective solution because it has a negative impact on remote stakeholders.

      When documenting risks, (see Independent in INVEST) avoid creating unnecessary Risk Work Items. Risks or concerns that do not need to be tracked by the Project Lead can be documented in the User Story. For example: Given a set of User Stories that align to CRUD, the Delete User Story usually has a dependency on the Add/Edit story. If for some half-cocked reason the Product Owner prioritizes the Delete story over the Add story and the team feels this risk/concern is not something the Project Manager needs to track, documenting the concern in the user story is preferred over creating a risk work item.

  3. Split User Stories

    • Consider splitting user stories that are too big to fit in a single sprint. (Slicing a large user story into multiple small stories that focus on specific architectural layers is not an appropriate strategy for making stories smaller. For example, splitting a large user story into a UI user story, a database user story, and a business logic story is not an appropriate way to make stories smaller.)
    • Develop a mitigation plan (an action to reduce risk) for any user story that can’t be split. This plan may be documented directly in the user story itself.

  4. Estimate User Stories

    • Choose a relative estimation method (e.g., Planning Poker) and document it in your team procedures.
    • User stories may be estimated/sized in a backlog refinement meeting or in a separate more narrowly focused sub-team backlog refinement meeting (i.e. Developers and Testers.)
    • Story points are recorded in the Story Point field in the user story work item. Stories without points are not considered refined.

  5. Review Higher Level Requirements

    • Periodically review epics and features to ensure they align with the team’s definition of refined and educate the team before breaking them down into lower-level requirements.
    • Teams may define a separate cadence for higher level requirements since they typically require less frequent review.

  6. Track and Resolve Issues

    • Track issue work items blocking the development of requirements (e.g., epics, features, and user stories). Refer to the Manage Issues activity for guidance on managing issues.
    • Develop and track corrective action plans for each issue to resolution.

    Note

    Backlog Refinement is an ongoing collaborative effort. It may be difficult to tell the difference between normal user story development and an impediment that is severe enough to create an issue work item.

    For Example: If the development team asks a question that only the customer can answer and there is a high degree of confidence the customer will answer the question in a timely manner, this may not be a good candidate for creating an issue work item. This is a normal scenario when refining a backlog and has no expected risk. Creating issue work items for this example, would just add noise to the issue backlog.

    Now, if the customer cannot answer the question in a timely manner and the item is important enough that the Project Manager needs to track it, this is a candidate for creating an issue work item (according to the current manage issues activity within the process guidance.)

  7. Prioritize User Stories

    • The Product Owner stack ranks user stories to reflect the order in which work should be performed. The PO and team develop their own criteria for stack ranking, which must include the customer’s priority and should consider the size and impact of implementing.

      Note

      Backlog Refinement is an ongoing collaborate effort. It is appropriate for the backlog priority to change multiple times during the refinement process. Changing the priority does not require a meeting. The priority will be frozen in the Plan a Sprint Activity.

Exit Criteria

  • Refined User Stories are stack ranked (prioritized).
  • User Stories are refined using the INVEST criteria.
  • User Stories or Bugs meet the team definition of refined.

See Also

INVEST

Process Guidance Version: 10.4