In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
Agile Scrum backlog grooming and management
Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed product backlogs.
We all know the “Definition of Done” used in Scrum for items that should be potentially shippable to the customer at the end of the sprint. In his book Essential Scrum, Kenneth Rubin discusses the “Definition of Ready” that applies to product backlog items that should be ready to be developed before the start of the sprint.
Product backlog refinement (or grooming) is an important activity in Scrum projects where user stories are prioritizes, right-sized and estimated. In his book “Agile Reflections”, Robert Galen provides some hints about how to verify that that product backlog grooming has been done successfully and that the right requirements information is available for the next sprint.
It can be complicated to involve the whole team to facilitate product backlog refinement and take part in requirements discussions. I would like to suggest a structure of the PBR (product backlog refinement) meeting that will encourage everybody to speak up and share their ideas on functionality.
The product backlog might be the more important item for a Scrum team as it represents the business value that the project should deliver to its customers. Putting a priority on the features and user stories is however not always easy for the product owners, especially if they are dealing with multiple stakeholders. In this article, Samantha Laing shares a technique that can help to improve the results of this activity.
A product roadmap is a high-level plan that shows how a product is likely to grow over time. This creates a continuity of purpose, aligns stakeholders and facilitates prioritisation. Unfortunately, many product owners and teams struggle with their product roadmaps. The roadmaps are often dominated by features, and the features are sometimes regarded as a commitment by senior management.