Backlog Refinement (once a week, every week)

Product Backlog

Backlog Refinement 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. The A2F Framework recommends to do Backlog Refinement once a week and to have at least two sprints worth of work items (i.e. User Stories) ready for delivery. In general, the following activities occur during Backlog Refinement:

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

Backlog Refinement is typically associated with the Scrum Framework, and the Product Backlog is the heart of Scrum planning: requirements, release planning, progress tracking.

  • What to put in the product backlog?
  • Everything related to the developed solution.
  • Stories (requirements), defects, spikes, etc.
  • Anything that needs a business decision.
  • E.g. significant development decisions with trade-offs.
  1. Two important differences to traditional requirement specification:
  • Product Backlog is not expected to contain all requirements at the start of the implementation.
  • All the stories in the PB are not expected to be delivered by the team.
  • It may be the goal in a specific project, but there is no general expectation that it is so.
  1. The level of detail is different.
  • Requirement specifications try to be comprehensive and accurate to the detail.
  • Product backlog is an overview and placeholder for details passed in written or oral form.

User Story

As a user I want something to gain a benefit.

Conversation

Notes:
UX Assumptions:
Technical Assumptions:
QA Assumptions:
Business Requirements:

Acceptance Criteria BDD

Test Scenario:
Given a <pre-condition>
When an Action occurs
Then a <post-condition>

Example:
| pre-condition | post-condition |
| example 1 | example 2 |

A Backlog Refinement session is typically attended by the following people and adheres to the below best practices:

Attendees: Product Owner, Scrum Master, Team, and invited SMEs if needed.
Once a week, a Grooming ceremony should be conducted to review backlog items and estimate them accordingly. This ceremony should be timeboxed to 1 hour a week, every week. The Backlog Refinement ceremony should follow the below guidelines:
Input:

Prioritized Backlog and groomed stories from the Product Owner perspective.

  • Product Owner will drive the Backlog Refinement ceremony and should schedule it on the calendar for their Teams.
  • Product Owner will bring up the backlog of prioritized work items in JIRA to review with the team.
  • Product Owner reads out each prioritized product backlog item starting from the top prioritized item.
  • Team discusses, asks questions, and does high level technical analysis for the product backlog item.
  • If the story is a Technical Story, then the team member who wrote the story will read it to the team. The team will discuss, asks questions, and do any needed high level technical analysis for the product backlog item.
  • The Team will then proceed to estimate the story. Large stories, typically stories with estimated story points of thirteen or higher, will need to be decomposed into smaller Stories. Product Owner should do this offline. As a rule of thumb, if the Story is too big to be completed by one “ideal” person in the Sprint, then it should be treated as a large Story that needs to be broken into smaller Stories.
  • Team estimates each backlog item using the Fibonacci Scale (0, 1, 2, 3, 5, 8, 13, 21, 34, 55…). The backlog items are estimated based on relative complexity. Complexity is defined as effort, risks, and unknowns, and is relative to the baseline Story. Therefore, each team should have one baseline Story that can be completed in 1 ideal day, and give that Story an estimate of 1 point. When the Team does relative sizing, they are comparing the Story size to the baseline Story. For a Story committed to a Sprint, the Story size should be 8 points or less.
  • If dependencies surface (i.e. Spikes, Technical Stories, etc.) in the discussion and therefore, affects the priority of the User Stories in the backlog, then the backlog has to be reprioritized.

Output:

Top prioritized Stories were discussed with the Team and estimated by the Team.

Note: If the stories are not initially groomed by the Product Owner, then use this meeting to pull in only critical members from the team to help initially groom the stories.
Note: For remote team members, it is important the Scrum Master utilizes a screen sharing services, such as WebEx, to share his or her screen.
Note: Ideally, you want to have two Sprints worth of Stories groomed.

Definition of Ready

The Definition of Ready (DoR) is a list of criteria used to determine when a Story or Feature “Ready”. A Story is ready to be pulled into a Sprint Commitment. A Feature is ready to be broken down into Stories. Below is our Definition of Ready at the Story and Feature level:

Story

  • Acceptance criteria has been discussed with the team and is updated. All field-level validations, mock-up screens, etc. have been added to the associated stories.
  • No dependency on other Team Backlog items. Stories pulled into sprints should not have outstanding dependencies on other stories unless the dependencies will be resolved in the same sprint.
  • User Stories have been written in accordance with the INVEST* model.
  • Performance Criteria documented (if applicable).
  • Backlog Owner has prepared and prioritized stories in the Team Backlog for at least two sprints.
  • No critical open questions.
  • Compliance met and defined.
  • Assumptions are validated.
  • External dependencies must be resolved.

Feature

  • Business and Technical Features have been prioritized.
  • Feature Title, Descriptions and Acceptance Criteria has been defined.
  • Supporting Business and Technical designs.
  • Relative T-shirt size.
  • Business Value.