The Product Backlog is a list of the product requirements for intended for future development, listed in priority order usually from top to bottom with the top being highest priority. Items at and near the top should be ready or near ready for the development team to pick up and begin work, safe in the knowledge that the item contains sufficient information to deliver a piece of work during the sprint.
User stories and use cases help all parties to understand where a requirement came from and what is the intention in developing such a solution, with a focus on value derived from the completion of a feature.
The product owner is responsible of and the sole owner of the product backlog, ensuring the information in each requirement ticket is up-to-date and in priority order.
Each product backlog item should include the product owner’s assessment of business value, ideally supported by data often provided by a business analyst. As items graduate to the sprint backlog they are each assigned a value to represent perceived development effort, this assists the development team in; declaring a reasonable sprint commitment, informing the product owner if an item may be too large, and give a clear indication of development velocity.
Product Backlog items typically exist as:
- features (wanted functionality)
- bugs (unwanted or unintended functionality)
- technical work (e.g. performance analysis)
- knowledge acquisition (research)
The Sprint Backlog is the list of items committed to by the development team for the given sprint. The commitment is an estimate and not a promise to deliver the work by the sprint review ceremony, the development team can use past performance in the shape of a velocity metric to more accurately predict what can be delivered. During the first few sprints where past performance is not available, it is expected that the commitment will be a best guess and likely to be wrong.
Sprint Backlog items are never assigned to a particular team member, instead items are addressed in order of priority and taking into account available skills within the team. This process of self-organisation encourages the team to maximise their strengths to promote the highest velocity possible.
The Sprint Backlog belongs to the development team and is usually applied to a sprint board.
The Sprint Board is a physical or digital board consisting of multiple columns to visualise a sprints progress at any given time. The number of columns can vary but a typical board will have To Do, In Progress, Code Review, Testing, Done.
Team members move items from left to right a they are developed until they reach Done, at the end of a sprint the items in Done are considered ready and part of the potentially shippable increment or product increment.
The Product Increment is the collection of Done items at the end of a sprint increment, successfully integrated with the work of all previous sprints. It is up to the product owner whether the Product Increment gets shipped or is put on hold until a future date.
The Product Increment is demonstrated to stakeholders to enable visibility and encourage collaboration and discussion of what to work on in the next sprints. Once the demo has concluded and sprint retrospective has been completed, the development team return to the product backlog to begin the next sprint.