Scrum Artifacts allows teams and organizations to iteratively and incrementally deliver valuable products of “Done” working releasable software within a Sprint. Key focus areas are Product Backlog, Sprint Backlog & Increment.
Scrum defines three artifacts: Product Backlog, Sprint Backlog, and a potentially releasable product increment. Artifacts defined by Scrum are specifically designed to maximize the transparency of information related to the delivery of the project, and provide opportunities for inspection and adaptation. Definition of “Done” is part of Artifact Transparency.
Scrum Artifacts – Product Backlog
User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. User stories are often written on index cards or sticky notes and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. Working software is more important than comprehensive documentation but that doesn’t mean documentation is not required. The goal in Agile should be to find the right balance between documentation and discussion. The team should determine what level of documentation is appropriate and produce just enough documentation. So user stories are part of the Product Backlog & contain only enough detail for planning and development, which will need to be supplemented by further face-to-face conversations during the execution of iteration/sprint
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. It is ordered based on their value to the highest priority items that will be on top. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.
Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.
The Product Backlog is dynamically changing and improving; it is never complete. It is a living artifact, changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. If there are non-functional requirements like security, and performance concerns raised in the middle of the project then production can add those to Product Backlog as well as Definition of Done so that those NFRs can be addressed in each increment otherwise it will be a technical debt later. Non-functional requirements describe the qualities of the Product being developed.
The Developers are responsible for all estimates. The Product Owner may influence the Developers by helping them understand and select trade-offs, but the people who will perform the work make the final estimate.
Let’s take a scenario: Scrum Team is ready to first Sprint but the Product Backlog is incomplete, what is the best possible thing Scrum Team should do?
Answer: Remember that the Product Backlog is never complete, and you don’t have to wait until you have everything in the Product Backlog to start the first Sprint. Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. However, this scenario says that the backlog is not “ready”, which probably means that a few items at the top are too large and/or unclear. Again, having unready items is not a reason to wait (still undesirable though); you can refine them during the Sprint but select other high-value items for the current sprint. The Product Backlog is a dynamic concept that is never complete. You don’t have to have all the items identified before starting the first Sprint. In scrum, events are time-boxed and events are not skipped. Sprint can be canceled only when the sprint goal becomes obsolete.
Product Goal: The Product Goal describes a future state of the product that can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Scrum Artifacts – Sprint Backlog
The Sprint Backlog consists of
- The Sprint Goal will help describe the real meaning of the items and direct the efforts of the Developers (why).
- A number of items are selected from the Product Backlog, based on their estimated work and the estimated capacity of the Developers (what).
- A detailed plan for delivery of the items and realization of the Sprint Goal during the Sprint (how).
It is a plan by and for the Developers. It is owned by all developers so there is no pre-assignment or developers should not volunteer to own Sprint Backlog items once they are available during sprint execution. Developers pull the sprint backlog items as per the availability. To ensure continuous improvement, it may include a few high-priority process improvements identified in the previous Retrospective meeting. The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal.
As new work is required, the Developers add it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed but to drop any planned items they must negotiate it with the Product Owner. During this negotiation. Only the Developers can change their Sprint Backlog during a Sprint.
The Developers track this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. So Sprint Backlog should have enough detail that they can inspect their progress in the Daily Scrum.
Sprint Goal: The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog. It provides flexibility in terms of the exact work needed to achieve it & guidance to the Developers on why it is building the Increment. It also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
During the sprint, if the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
Spike: It is a task/story aimed at answering a question or gathering information, rather than at producing a shippable product. Sometimes a user story is generated that cannot be well estimated until the developers do some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.
Scrum Artifacts – Increment
An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. It is a concrete stepping stone toward the Product Goal. In other words, Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” The sum of the Increments is presented at the Sprint Review which supports empiricism.
The increment must be in useable condition regardless of whether the Product Owner decides to release it. An Increment may be delivered to stakeholders prior to the end of the Sprint. Multiple Increments may be created within a Sprint.
Each increment(s) released by each Scrum team at the end of a Sprint must be potentially shippable. If they don’t:
- The state of the product is unclear (due to not yet discovered problems that will arise during integration and complete product increment tests)
- The Product Owner does not have a clue whether the increment he/she was presented is potentially shippable
- It is not transparent to the organization what the next reasonable steps are (if their difficulties due to integration, the next steps would be rather clear, but not integrated – it’s only wishful thinking)
Table of Contents (PSM ™, PSPO ™ & PSD ™ Certification)
- Scrum Framework – Scrum Theory
- Scrum Framework – Scrum Roles
- Scrum Framework – Scrum Events
- Scrum Framework – Scrum Artifacts
- Scaling Scrum – DoD – DoR – Scrum Framework
- Developing People and Teams
- Managing Products with Agility
- Developing and Delivering Products Professionally
- Evolving the Agile Organization – Scaled Scrum, Portfolio Planning & EBM