The three-staged Product Backlog we proposed earlier has gates between the stages. These gates are checklists verifying the requirements quality. In a proper tooling, such a checklist can function as an automatic gate between the different stages.
In the following section we give some example checklists for all of the 3 stages. They can also be seen as the definition of the “Done” metaphor in Scrum.
The following diagram of the Product Backlog is an overview of important checks, responsibility and participation of the Product Owner and the Team in the creation of the requirements.
Diagram 32: three-Stage Product Backlog with tasks and roles
The documentation artifacts produced need to be clearly defined beforehand. The Product Owner has to decide which artifacts should be produced and at which stage in compliance with company standards.
The Product Owner collects ideas, unspecified features, change requests and non-critical technical refactoring’s. When an Item enters the Product Backlog at this stage, the Product Owner should have a minimal set of information attached (i.e. source and
date). He works on the refinement of these Items when he deems it necessary. At this stage it is optional for him to consult with the Team. He is strongly advised to work with the Team to assess the risk, impact and rough estimates.
When an Item is important enough to enter the stage of detailed requirement engineering, the following quality gate has to be passed.
Table 6: Stage 3 – Quality Gate
The Product Owner works with his Stakeholders and the Team on the refinement of the requirement. Functional and non-functional aspects are separated and acceptance criteria from a business perspective are formulated. The Team’s involvement is necessary to ensure the requirements are well understood and a consensus exists. The minimum involvement the Team has at this stage must be enough for a sound understanding of the requirement so that it can deliver a sound story point estimate for it.
When an Item is important enough to enter the stage of technical refinement and planning preparation, the following quality gate has to be passed.
Table 7: Stage 2 – Quality Gate
Appropriate techniques to refine the rough requirements of Stage 3 are user stories with the associated acceptance criteria, system use cases, possibly with a description of the standard workflow and possible alternatives, as well as UI-mockups and flows. These technical artifacts must be assigned to the corresponding quality requirements.
The Team works on Product Backlog Items to enrich them with technical details and work preparations when it deems necessary. They work with the Product Owner to clarify final questions and details of the requirement. When needed, a detailed Work-Breakdown-Structure functions as good preparation for the Sprint Planning.
When an Item is ready to enter the stage of Sprint Planning, the following quality gate has to be passed.
Table 8: Stage 1 – Quality Gate
Typical techniques within the technical specification are data models (e.g. ER-models, UML-class diagrams), state diagrams, sequence diagrams and formal interface descriptions.
The Product Owner manages this process and sets priorities in the interests of the ROI. While the above process is more formal than the Product Backlog Refinement, it helps to assure well-documented and high quality requirements that are mandatory in many application domains. It is the Scrum Master’s responsibility to balance the formal and informal aspects of requirements engineering and to cultivate close cooperation and communication between the Product Owner and the Team within the project.