Scrum Artifacts
Artifacts are perceived and recognized “Visual Aids”. In a co-located Scrum team, artifacts play a vital role for the team to reflect themselves on how they are doing with the sprint goal. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
As per the latest Scrum guide, Scrum framework defines 3 essential artifacts.
Artifact #1: Product Backlog
- The Product backlog is a set of all baseline requirements prioritized in order which is made available by the Product Owner to the Scrum Team. The product backlog emerges and evolves over time and the Product Owner is responsible for its content and validity.
- The Product backlog is a living artifact that may be subjected to change, when there is a change in the external business environment, market conditions, regulatory changes or technology changes.
- Scrum teams work on the Product backlog and create a potentially shippable product increment which is demoed to the customer. The feedback from the customer is appended to the Product backlog.
- Product Backlog refinement, also popularly known as Backlog grooming, is an informal Scrum team ceremony that happens every sprint, in which everyone in the team, including Scrum Master and Product Owner get together to ensure that work items in the backlog are relevant and useful, and each items aligns to the overall product roadmap. It is indeed more of a working session than a typical closed door meeting.
Typical activities during the backlog refinement are
- Reviewing the highest priority stories on the top of the backlog
- Ask questions to product owner for more information.
- Deleting stories that are no longer needed
- Writing new user stories
- Re-prioritizing and force ranking the stories
- Re-define the acceptance criteria
- Creating new user stories when necessary
- Estimating or re-estimating stories
- Re-assessing the relative priority of stories
- Breaking the epics further into user stories
- Refining stories to prep for future sprints
- Understand the changing bigger picture of the product architecture as the backlog emerges.
Artifact #2: Sprint Backlog
- Sprint Backlog is considered as the topmost subset of the Product Backlog that the team pulls into the sprint to work on. It is essentially the list of “To Do’s” a development team might be working during the current sprint.
- The work items in the Sprint Backlog are broken down further into tasks by the team. All items on the Sprint Backlog should be developed, tested, documented and integrated to fulfil the commitment.
- The Sprint backlog formation is usually guided by the Sprint Goal. It is a forecast by the development team on what functionality the team will have to work and deliver.
- The Product Owner helps the team to come up the sprint goal during the sprint planning meeting.
- The Sprint backlog can be changed by the Scrum team as it evolves. The development team may discuss the work in progress during the Daily Scrum and modify the Sprint Backlog throughout the Sprint, as the Sprint Backlog emerges during the Sprint.
- As new work is required, the Development Team adds 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.
- Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
Artifact #3: Product Increment
- The most important Scrum artifact is the Product Increment. Each Sprint the development team produces potentially shippable product increment. This product increment must align to the development team’s “Definition of Done” and this increment must be acceptable by the Product Owner.
- This product increment must be the sum of all the Product Backlog items completed during the current sprint and the value of the increments produced during all of the previous sprints. The Product increment must be in a usable condition regardless of when the Product Owner decides to actually release it.
- The Product increment is a piece of working software that creates transparency to all the stakeholders. The team may also create other optional additional artifacts like burn down charts and task boards
Definition of Done
When the Product Increment is delivered, it needs to meet “Definition of Done” which is a shared understanding document of the development team regarding of what “done” means. This definition is different for every Scrum Team, and as the team matures, the Definition of Done will expand and become more stringent