Refine two sprints to definition of ready
Refine two sprints
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 a 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 two 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 the 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 the 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 ensures that the entire team understands what should be built for backlog items, which may be in the sprint scope. Be mindful and include other roles who can shed light on a backlog item and the relative size of effort in refinement sessions, such as an experience designer, 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.
Definition of ready
The definition of ready (DoR) refers to a user story that is ready to be built. If a user story meets the definition of ready, it has met the entry criteria for sprint planning and is, therefore, ready to be built.
If a user story does not meet the DoR, it increases the risk that the user story does not contain the right information that can lead to rework or take the solution in the wrong direction. If a user story does not meet the DoR, it can, therefore, be rejected by the Scrum team in sprint planning.
The definition varies from project to project. This is an example that can be tailored to each individual project.
Consideration points for definition of ready:
- The user story is aligned to the sprint objectives and the business value/outcome is clear
- All acceptance criteria in the scope is identified and refined (functional, technical, non-functional, performance, UX)
- The user story has been documented clearly enough so that the build and test team can make an informed decision as to whether it can be accomplished within a sprint
- All dependencies (internal and external), issues, risks, blockers are identified
- The user story has been reviewed by the UX team and includes UX artifacts
- The user story has been sized by the delivery team (development and test)
- The user story can be built and tested within one sprint. If not, the user story should be split into smaller user stories
- The user story has been accepted by the participants in a three-way handshake (BA, development and test teams)
- The user story is defined within the Journey Centric Test Plan
- The user story has been reviewed and accepted by the product owner
- The user story has been reviewed by LSA for technical feasibility