Scrum Artefacts
Scrum artefacts are intended to provide transparency for the work and invite their inspection and subsequent adaptation.
Product Backlog
The Product Backlog represents a single source of requirements, features and changes needed for the work and is an ordered list that is managed by the Product Owner. The Product Backlog is never static and should reflect the current understanding of the product. The Product Backlog should be continually curated and updated with new items added and superseded items removed as part of the Product Backlog Refinement activities. Highest ordered items should be more detailed with lowest order items less so.
Practical Tips
| Story Mapping | Using Story Mapping[11] techniques can really help to bring a Product Backlog to life and provide more dimensions to consider during Product Backlog Refinement activities and Sprint Planning than just an ordered list.
Seeing everything laid out can help Product Owners and the Development Team see patterns and strategies to help to determine the best possible value that can be delivered. |
| Avoid Tool Solutions | In a scaled environment it can be tempting to look for tools to be the solution to problems without really understanding what the underlying problems are.
Ensure that the problems are thoroughly understood before tool solutions are proposed. |
| Physical Vs Electronic Tools | A physical Product Backlog on a wall with index cards can be a great way to visualise the product, understand the context and see patterns that can help to derive a strategy for delivery. They can be big and bold, and show everything at a glance.
Electronic tools by comparison can show items on a screen and may be subject to the resolution of that screen. They are great for distributed teams to understand what is needed for the product to be delivered, but may not provide that strategic thought pattern that would be possible with a big physical Product Backlog that is immersive. |
| Living Product Backlog | The Product Backlog should be a living representation of the current understanding of the product and the value that it provides, and should be continually curated and updated with what is currently known. |
Sprint Backlog
The Sprint Backlog is a highly visible forecast by the Development Team of what items are to be worked on during the Sprint and shows a plan of how the work is to be done to meet the Sprint Goal. During the Sprint the Development Team constantly update and curate the Sprint Backlog to reflect the current understanding of the work towards the Sprint Goal. A Sprint Backlog is intended to aid the transparency of the work and can be inspected throughout the Sprint and during the Daily Scrums by the Development Team so that they can adapt accordingly. New work for the Sprint Goal may emerge throughout the Sprint and can be added by the Development Team to the Sprint Backlog during the Sprint. (This is to “refine” the work towards the Sprint Goal, rather than changing the Sprint Goal, which would be a change in direction and disruptive to the team.) Since November 2017, the Scrum Guide also stipulates that at least one high value improvement item from the previous Sprint Retrospective is included on the Sprint Backlog for the Sprint.
Practical Tips
| Visual Management | Making the Sprint Backlog highly visible can help the Development Team to make good decisions on how to adapt during the Sprint. |
| Physical Boads vs Electronic Boards | Using a physical board with a collocated team really helps with the interactions, as teams can see everything at a glance, physically move things around whilst talking about them, and they can be customised to support how the team are naturally working.
The downside is that a physical Sprint Backlog is time consuming to copy the data in electronic form if needed. Also, being quite physical it can be subject to the natural elements such as wind and gravity. Using electronic boards tend to work well when teams are distributed and an electronic record of the work is needed. They can provide some metrics and metric calculations instantly. However, the interactions are not as rich as a physical board, as team members cannot physically interact with the items. The size of the board is limited to screen size and resolution even if using them with a data projector. Also, the Development Team may *have* to work in the way that the electronic tool has been devised, which can be restrictive. |
| Located Near The Development Team | If a highly visible Sprint Backlog is located near where a team is working, it will most likely be updated more often and more accurately than if it is located somewhere away from the team. |
| Daily Scrums | Hosting the Daily Scrums next to the Sprint Backlog usually has the benefits of being constantly updated and providing context for discussions during the Daily Scrum |
Increment
The Increment is the sum of all of the work completed in the Sprint towards the Sprint Goal and which meets the Development Team’s definition of “Done” to be potentially releasable. “Potentially Releasable” is a condition where the Increment could be released in its current form with no additional modification or work to be done, should the Product Owner decide to release it.
See Also
- Scrum Framework
- Sprint Planning & Product Backlog Refinement
- Product Backlog Refinement
- Product Backlog Items
- Working With The Product Backlog