b is for...
In general a backlog is a set of items of work to be done or that might be done. A work item may be a change to an existing product feature, a new feature, a fix for a defect, a change in the environment that the product runs under, or any other activity that may contribute to its value such as a refactoring of software.
In the scrum framework and other agile approaches, a product backlog or release backlog is ever-evolving and continuously updated. It is the single source from which work items are discussed, refined, selected, and committed to. Backlog items may be at different levels of detail, some with sufficient detail that they are ready to be implemented, others with a general description that will need further refinement. Backlog items may use different formats such as user stories.
A backlog item may include its business value as provided by the customer. It may include a size that is an estimate of the amount of effort to implement it. A backlog may have its items sequenced into an ordering in which they are to be implemented, where the order is determined by considering business value and size along with other factors such as dependencies.
In addition to the product backlog, an agile team typically creates a backlog specifically for each development iteration, known as an iteration backlog or sprint backlog. The items in a sprint backlog are drawn from the product backlog. Those items should be considered sprint ready.
Backlog refinement is the process of adding new user stories to the backlog, re-sequencing existing stories as needed, creating estimates of effort for previously un-estimated stories, and decomposing large stories into smaller stories or tasks.
Backlog refinement is both an ongoing process as well as more specifically the event or ceremony that occurs regularly within a team’s iteration cycle to accomplish the above.
Scrum trainer and consultant Roman Pilcher explains the significance of backlog refinement to the agile development process: “Grooming the product backlog collaboratively creates a dialogue within the scrum team and between the team and the stakeholders. It removes the divide between “the business” and “the techies.” It eliminates wasteful handoffs, and avoids miscommunication and misalignment. Requirements are no longer handed off to the team; the team members co-author them. This increases the clarity of the requirements, leverages the scrum team’s collective knowledge and creativity, and creates buy-in and joint ownership.”
Scrum Alliance founder Ken Schwaber recommends that teams allocate 5% of their time to revisiting and tending to the backlog.
Background Of The Term
This was originally called “backlog grooming” but was changed in 2013 due to the current negative connotation of “grooming”.
The ceremony is also known as “backlog maintenance” and “story time“.
Backlog Refinement – Agile Alliance glossary
Daddy, Where Do Product Backlog Items Come From? – Agile Learning Labs – blog post
What NOT to do during Product Backlog Refinement? – Serious Scrum – blog post
Plots units of work that remain to accomplish (Y axis) against units of time (X axis). In Scrum, the Burn Down Chart is a key artifact.
Release Burn Down
The units of work that appear on a Burn Down Chart are derived from the Release Backlog. During the process of Backlog Grooming they have been assigned an estimated point value. The trend line on a Release Burn Down Chart will generally trend downward, however, if new items are added to the Release Backlog, then the total points remaining may go up.
The Release Burn Down Chart is the primary tool a team has for visualizing their velocity, the average number of points they accomplish during an iteration.
Iteration Burn Down
The initial point value of work remaining in a Sprint Burn Down chart derives from the work the team commits to accomplish during the Sprint. Work remaining is generally graphed daily. The number of points the team undertakes is based on their established team velocity, i.e., the number of points they routinely complete. In Scrum, no new work may be added once a sprint has begun, so the trend line will never rise. In Extreme Programming, work may be added during a sprint, so the trend line may rise.