Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Scrum Artifacts with pictures

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

Related image

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.

Related image

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. 

Image result for CRUD

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.

Image result for product Increment

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.

Related image

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. 

Related image

 

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. 

Image result for product backlog iceberg

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.

Image result for product backlog

Sprint Backlog

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

Image result for sprint backlog gif

 

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.

Image result for sprint backlog gif

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.

4 comments

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

This. 100% this 😄thanks for sharing

Like Kat Warner _TechTime_ likes this

@Kat Warner _TechTime_  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. 

Like Kat Warner _TechTime_ likes this

@Amandeep Singh 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.

Like Amandeep Singh likes this

@Kat Warner _TechTime_ 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.

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Agile

On-demand: Fireside chat with Atlassian on scaling agile organizations

Scaling an agile organization and setting it up for success over the long term is a hard thing to do. We hear a common set of questions from customers all the time, questions like: Can agile scal...

3,959 views 2 17
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you