Skip to content

7. Techniques

7.1 Backlog Refinement

Agile Extension to the BABOK® Guide

Backlog Refinement is used to ensure there is enough detail and clarity for items in the backlog so that the delivery team can complete an iteration.

Backlog Refinement is a continuous technique used to prepare product backlog items for an agile team to deliver. This is frequently done in preparation for a Planning Workshop. Backlog Refinement incorporates ongoing feedback and learning to revise and refine requirements of needs on an ongoing basis. Refining the backlog based on stakeholder feedback is a critical differentiator for agile initiatives. Backlog Refinement assists the delivery team in delivering a high value, high quality solution within an iteration.

Business analysis practitioners collaborate with team members, stakeholders, and customers to clarify the need and identify additional detail. This can include reviewing priorities with stakeholders and moving or removing items as necessary.

Refinement activities vary based on what is needed to prepare the item for the delivery team. Activities may include Story Elaboration, Story Decomposition, prioritization, and sequencing. Backlog Refinement clarifies which items are high priority for the team to deliver and re-prioritizes or removes unnecessary items.

Backlog Refinement splits large items into smaller ones that meet the INVEST criteria (for more information, see 7.21. User Stories). Acceptance criteria or additional documentation needed to deliver an item can also be added.
Refinement for an item is complete when there is sufficient information for the team to execute.

The outcome of refinement is a common understanding among the team of what is required to deliver the product backlog item (PBI). It also gives the team a chance to look ahead at what is expected next for the solution.

.1 Backlog
An ordered list of features, requirements, or items needed to achieve the outcomes for the solution. Refinement refers to the activities to keep the backlog relevant and timely for the team.

.2 Backlog Item
An item on the backlog which represents one or more requirements. Items higher on the backlog are appropriately sized and include enough detail for the team to complete in the next iteration. Items lower on the backlog can be larger and less defined.

Items are most commonly presented as a user story (for more information, see 7.21. User Stories), but can be presented in other formats such as job stories (for more information, see 7.4. Job Stories) or wireframes.

.3 Refinement Meeting
The purpose of this meeting is for the team to review items that are at the top of the backlog. The outcome of this meeting is confirmation that the top items are ready for the next iteration and identify any further clarity needed. There is no standard format for this meeting, but it is most often led by the product owner or customer representative.
The output of the refinement meeting is backlog items ready for the next iteration.

.4 Definition of Ready
This is a set of criteria the team agrees must be satisfied to consider an item "ready" for the next iteration. Initially, teams can set the criteria as a critical mass of team members agree the item is ready for the team. As the team reflects and looks to continuously improve, the team may identify additional criteria for their initiative.

.1 Strengths

  • Increases clarity and common understanding of a product backlog item (PBI).

  • Facilitates more effective iteration planning by raising queries early.

  • Gives the product owner or customer representative time to answer queries before the team begins executing.

  • Ensures product backlog items (PBIs) are sized appropriately for the team.

.2 Limitations

  • Can be inefficient when not aligned to the cadence of the team. If the team reviews the backlog daily as in a flow approach, then refinement should happen whenever a new backlog item is added. If the team reviews the backlog incrementally, then refinement should happen several days before a planning meeting.

  • Is usually done by a few members of the team and can inadvertently preclude the views of team members not directly involved in the activity.

  • Can be ineffective if the vision and roadmap change frequently.