Product Backlog refinement is the process through which Product Backlog items are reviewed by the team and revised, providing more detail and ensuring that there is greater clarity in the requirements for that item. This is an ongoing activity, whenever any new information is available about a backlog item. Depending on the size of the backlog, it can be useful to have a planned mid- Sprint session that allows for candidate Product Backlog items for the next Sprint to be discussed. This session helps to kick-start Product Backlog refinement activities, with revisions being finalized during the Sprint planning session.
The Product Backlog is never complete. It is a living document that evolves with greater understanding of the product, client and market. The backlog should be visible and transparent to the Scrum team and stakeholders, and should be always in a “ready” state, meaning that anyone should be able to look at the backlog at any moment and be confident that the priorities, sizes and content are accurate and up-to-date based on the latest information. A general rule of thumb is that a backlog should not be left unattended for more than 2 days. There should always be at least two sprints worth of sized high-priority User Stories that are ready for the development team to work on.
You aim to define two sprints worth of work ready for build. You need two sprints because sometimes things change and you cannot work on an item (key people are sick, interfaces are late etc.) By having two sprints of work, you have a safety net of work to keep the team busy.
There are various types of artifacts and documents to manage and store such as user stories, flowcharts, goal, objective, etc. You may be using one of the multiple repositories which exist for these artifacts such as SharePoint, VCS, network drives, or even one’s local hard drive. All of this makes for a very chaotic situation and will negatively impact the efficiency of the project team and quality of the work product.
In a Pega project, Direct Capture of Objectives (DCO) empowers backlog refinement by directly capturing requirements in Agile Workbench as Product Backlog Items (PBIs).
Backlog refinement with DCO ensures that enough information is known so that:
- Each item can be sized.
- A plan can be developed for how selected Product Backlog item can be delivered during Sprint Planning.
- The team can then commit to delivering Sprint Backlog items within the Sprint.
All members of the Scrum team should be involved in Product Backlog refinement. This ensure that the entire team understands what is should be built for backlog items, which may be in the Sprint scope. Be mindful and include others roles who can shed light on a backlog item and the relative size of effort in refinement sessions, such as User Interface, and database architect.
Have this meeting before the Sprint starts, so the Product Owner is given a chance to respond to questions - there may be some that would require some research or follow up by the Product Owner. If those questions were asked for the first time in Sprint Planning, it may become necessary to put a high-priority Product Backlog item aside and not work on it during the Sprint. Having this meeting before the start of the next Sprint gives the Product Owner sufficient time to act on any issues that are identified.
During a Product Backlog refinement meeting, the development team, Scrum Master and Product Owner discuss the top items on the Product Backlog. This is the opportunity for the developers to ask probing questions that would normally come up during Sprint Planning, such as “What should you do if the user enters invalid data here”, “what happens if…”, and other similar questions. An alternative approach and timeframe for backlog refinement meetings is to have weekly, but shorter meetings, which is also acceptable and dependent on the Scrum team’s preference for backlog refinement.