Scrum Artifacts with pictures

[#1]

One of the hats I wear at work is Scrum Master. In December I levelled up by attending a Scrum.org course, studying, and passing an exam to become a Professional Scrum Master. This article is the second part of a series where I summarise what I learned so I can share the knowledge with my team and with the Atlassian Community. The first article is here.

There are three Scrum artifacts recognised as essential in Scrum:

• Product Increment
• Product Backlog
• Sprint Backlog

Product Increment 

     The entire point of Scrum is to create a Done Increment

The benefit of using an agile project delivery framework like Scrum is the ability to deliver value to stakeholders incrementally. The way work is broken down affects the ability of the Development Team to deliver a potentially shippable product increments. When work is broken down with a focus on functionality, a Product Owner has the ability to approve done* work to be released to Production during as well as at the end of a sprint.

* The Definition of Done is an optional but very useful Scrum artifact I will talk about in a future article.

CRUD - breaking down work is hard to do. In this case, CRUD can offer one way to break down work in potentially shippable product increments and allow for iterative development. 

The idea is to break down work into deliverables, not actions. As someone with a project management background, this can be a tricky change in mindset as I am used to guides that talk about breaking projects into milestones, large tasks, small tasks, time-boxed tasks for weekly/monthly repeating work, etc. There is a great example of breaking work down by deliverables here using an aircraft system.

Having a functionality focus has other benefits. A deliverable is easier to test and review with stakeholders. This allows for timely feedback and the ability to make changes to the planned future deliverables rather than having to make changes to deliverables you already thought were completed.

While you continue to plan work based on actions, you will struggle to implement other parts of Scrum.

Product Backlog 

A Product Backlog is made up of product backlog items (PBIs) and is a list of defects, features, knowledge acquisition, and technical work related to the product. This is an ordered list with the expectation that each sprint will be filled up by taking PBIs from the top of the list. The Product Owner determines the order of PBIs in the Product Backlog working with other members of the Scrum Team and with stakeholders. 

Product Backlogs resemble an iceberg. Items at the top should be detailed enough for the Development Team to be able to deliver the item whereas PBIs further down the list may only have enough details to become epics which additional more PBIs are created underneath. 

Breaking down PBIs also helps you get RID of risks and allows you to allocate higher time estimates or story points if these are used:

• Requirements risks - like with plumbing, big things clog the system. Unclear requirements, large scope of work, or lack of contextual understanding are requirements risks.
• Implementation risks - you don't know what you don't know. Legacy codebases, poor test coverage, technical debt, or new and unknown technologies are implementation risks.
• Dependency risks - no man is an island. Technology product/platform dependencies, team members working difference schedules or in different timezones, or external people like clients, parents, or outsources development are dependency risks.

A high-quality Product Backlog is essential for building Sprint Backlogs that will deliver value efficiently.

Sprint Backlog

Everyone finds the Sprint Backlog exciting right? PBIs are ready to be transformed from ideas to reality

The Development Team takes PBIs from the Product Backlog in the order they have been organised but the Product Owner. Once the PBIs are in the Sprint Backlog it is up to the Development Team to determine the order of development that works best for the Development Team.

The Sprint Backlog is the collection of PBIs the Development Team forecasts they can complete within the sprint. This is a commitment that can be reinforced by having a Sprint Goal*.  The sprint backlog provides flexibility for the Development Team as they are only communicating a short-term forecast and stability for the Stakeholders as they know what they can expect to be available next. The Scrum Master works with the Development Team to remove impediments that may prevent them from delivering the forecasted work.

* The Sprint Goal is an optional but very useful Scrum artifact I will talk about in a future article.

TLDR: 

While there are a lot of artifacts associated with Agile and Scrum, only 3 artifacts are considered essential:

• Product Increment
• Product Backlog
• Sprint Backlog

Knowing what needs to be delivered and in what order are critical to success with Scrum.

[Fernando Bordallo]

> Knowing what needs to be delivered and in what order are critical to success with Scrum

This. 100% this 😄thanks for sharing

[Deleted user]

@Kat Warner  thanks for putting this.  From a Scrum Master point of view this was Verrry! well put thank you for taking the time and doing this. 

[Kat Warner]

@[deleted] thanks for the feedback - I appreciate it.

I hope to write a fourth article in this series about the common agile and scrum terms that are not in the offical scrum guide sometime soon.

[Deleted user]

@Kat Warner yes please do, will look forward to. It will be refreshing to see

For example take "backlog grooming" session with the PO/Team now being to refereed as "User story time" or "Story time" and I think we are now seeing changes in terminology in Agile which is fascinating considering Agile is fairly young.