Agile scrum artifacts

The term artifact is often associated with archaeological ruins and ancient relics. Yet in software development, the term artifact refers to key information needed during the development of a product. 

Agile has its own particular byproducts that emerge from the scrum experience of planning, development, tracking, and iteration of tasks to build software.

Agile scrum artifacts are information that a scrum team and stakeholders use to detail the product being developed, actions to produce it, and the actions performed during the project.  These artifacts provide metadata points that give insight into the performance of a sprint. They are essential tools for every scrum team since they enable core scrum attributes of transparency, inspection, and adaption.

Artifacts are created during the main activities of a scrum sprint: 

• Plan work and future goals
• Create tasks to achieve these goals
• Organize tasks into sprints based on dependency and priority
• Execute the tasks
• Review and analyze results in order to compare to the goals
• Repeat these steps

The main agile scrum artifacts are product backlog, sprint backlog, and increments.

The product backlog is a list of new features, enhancements, bug fixes, tasks, or work requirements needed to build a product. It’s compiled from input sources like customer support, competitor analysis, market demands, and general business analysis. 

The product backlog is a “live” artifact in that it is updated on-demand as new information is available. It’s a cross-team backlog that is maintained and curated by the product owner between sprint cycles and as any new ideas arise. It contains tasks that were once in an active sprint but deprioritized and moved to the backlog.

The sprint backlog is a set of product backlog tasks that have been promoted to be developed during the next product increment. Sprint backlogs are created by the development teams to plan deliverables for future increments and detail the work required to create the increment.  

Sprint backlogs are created by selecting a task from the product backlog and breaking that task into smaller, actionable sprint items. Consider an example task like “build a shopping cart page”, which requires many design and development subtasks. The product backlog is home to the primary task while the supporting tasks like “create a shopping cart visual design mockup” or “program the shopping cart sessions” are housed in the sprint backlog.

The sprint backlog is updated during the sprint planning phase of scrum. The smaller sprint tasks are assigned to the relevant teams like design and development. If a team does not have the capacity to deliver all the sprint tasks, the remaining sprint tasks will standby in the sprint backlog for a future sprint.

A product increment is the customer deliverables that were produced by completing product backlog tasks during a sprint. It also includes the increments of all previous sprints. There is always one increment for each sprint and an increment is decided during the scrum planning phase. An increment happens whether the team decides to release to the customer. Product increments are incredibly useful and complementary to CI/CD in version tracking and, if needed, version rollback.

Teams benefit from keeping all their work aligned to backlog items. For example, creating a branch and build for each backlog item. Teams that integrate their version control and CI/CD tools into their scrum tracking software can use information from those tools to better understand the progress of work. They can also reason about which backlog items are getting deployed and released to customers. This also lets the team reversely look at commits and then tie them back to a scrum increment to see the history and planning of that code.

In addition to the previously discussed official scrum artifacts, there exist some extended or meta artifacts. While not official per official scrum guidelines these extended artifacts add additional value and insight to a scrum cycle.

A sprint burndown (or burnup) chart is not an official scrum artifact but many teams use it to communicate and track progress toward the sprint goal during the sprint. Burndown charts are graphs that display tasks completed over the duration of a sprint. Burndown charts are very useful in helping to gauge the active execution velocity of a team so they know whether they will complete what is planned or need to reprioritize the sprint tasks.

During sprint planning, teams can look at previous burndown charts to get an idea of how many tasks they can realistically complete in an upcoming sprint.  Teams can examine in progress burndown charts to identify whether they are on target to successfully complete the sprint. During the sprint review, teams can revisit the burndown chart to see where they hit or miss expectations. Over time burndown charts help teams better refine their estimates during the planning stages of scrum.

It’s important that teams have a clear definition of “done”. This definition can be another type of artifact, which should be documented and shared. An example definition of done for a development team is when code is covered with automated tests that match a specification and is deployed to a production environment. A team without a clear definition of done will find themselves often in sprint review asking “is this done?” when reviewing open scrum tasks.

The definition of done helps define the boundaries of an increment. Increments should be delivered in complete usable packages that are additive to increments that came before. Done also defines when tasks are complete and can be closed out for burndown tracking.

Scrum artifacts are powerful aids that help teams operate more efficiently. Therefore, it's important all teams have access and visibility into the artifacts. Product owners and scrum masters need to make it a regular practice to review and discuss artifacts with development teams. This will help teams stay aware of operational inefficiencies and produce creative ways to improve velocity.