A deeper understanding on…

Scrum’s Artifacts

Road to PSM III — Episode 12

Sjoerd Nijland
Oct 3, 2018 · 8 min read
Image for post
Image for post
inspecting the artifact

As we’ve been running through this series we’ve been developing a deeper understanding of Scrum. Jeff and Ken have been somewhat mischievous in mentioning that Scrum is in the introduction of the Scrum GuideThey emphasise the importance of having a common language shared by all. We’ve been chewing through definitions like , , and next served are . The Scrum Guide is perhaps infamous for its linguistic magic.

Definition of ‘Artifact’

I learned that we don’t all share the same understanding of this term. Sometimes we can’t even agree on whether it’s ‘artfact’ or ‘artfact’. When I ask people what they think an artifact is, they generally tell me its an ancient/old excavated object.

The term originates from the latin “thing craftedby skillSomething could be also referred to as ‘’.

In Software Development, artifacts are created during software development. These are generally specifications, models/diagrams, test scripts, designs, prototypes and metrics. Some will refer to artifacts as surviving ‘legacy’ documents. They generally describe a historical desired to-be state of something that by then has already evolved. Therefore they are no longer all that reliable as these documents are rarely kept in a transparent state. They can be the source of a lot of andwhenthey continue to be used as a source for ongoing development. But as they no longer reflect the as-is state of the product, it results in all sorts of wasteful malalignments, misconfigurations and miscommunications.

Image for post
Image for post

By-products and Make-work

It’s all this bureaucratic madness that gave rise to the numerous alternative approaches to software development. The ever growing popularity of both the Scrum Framework and the Agile Manifesto are a testimony to this.

Many (software) development agencies work project based with a contractually agreed fixed number of hours to be spend on it. So one might argue that the more is spent on creating by-products, the less is being spent on crafting the actual product. With Waterfall, often half (if not more) of the project’s timebox has expired before the actual product starts emerging.

Image for post
Image for post

Waste

Many organisations have all sorts of ‘’ rituals. In the office we comfortably participate in all sorts of rituals and contribute happily to the development of by-products. We’ve come to value them. It makes us appear productive after all. We are providing valuable contributions; or so we all like to think. Many have come to value their individual ‘conveyor belt’ position along the Waterfall production line.

Image for post
Image for post

Likewise many have come to value their ‘white collar’ positions (being clerical, administrative and managerial) over those doing craft or service work, which traditionally ‘enjoy’ a lower salary and intellectual esteem.

Image for post
Image for post

Over decades we learned to value conceptual thinking/designing over creative and crafty production work. In many countries the educational system aligns to this.

Naturally we don’t consider ourselves to be massive time wasters. ‘Oh we’re so busy’ and we like to show it. Our agendas are overbooked, our inboxes swamped, our backlogs… endless. Being (or appearing) busy appears to be priority number one in the workspace.

Now with Scrum, like Kaizen we continuously change for the better. We create visibility over the way we work so together we can inspect the way we operate to try and improve overall efficiency. Counter to our intuition, this effort mainly revolves around the principle of : “”.

Now all this is not to say that producing artifacts isn’t valuable, in fact it generally is.

Three artifacts.

Agilists might reject Scrum’s artifacts for being what they are. However, those who are actually serious about reducing wasteful artifacts, could (ironically) embrace Scrum’s artifacts. They should serve to eliminate waste and act as containers that creates .

The Scrum Framework contains three artifacts:

  • Product Backlog — An ordered, single source list of everything that is known to be needed in the product.
  • Sprint Backlog — The Sprint Backlog contains the Forecast, plus a plan for delivering the product Increment and realizing the Sprint Goal.
  • Increment — The sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

Now, Scrum is a framework, we established that. All its components support each other. There aren’t all that many, it’s a lightweight framework after-all. The roles, events and artifacts will only truly be effective when they reinforce each other. Try to take anything out, and the whole system (which is your organisation) is likely to become unstable.

Roles

One of the reasons why a Scrum Master is a pivotal role, and, in my opinion one that should spend a fair amount of time collaborating and working with the team, is due to the following responsibility:

Scrum dedicates another role to ensure that the Product Backlog is well tended to. The Product Owner is responsible for:

We also learned who is responsible for the state of the Sprint Backlog:

Definitions of Done

Definitions of Done help to create transparency over the artifacts. They are needed to keep them in shipshape condition. The Definitions of Done and practises used to get Product Backlog Items in a state I will cover in more detail further down this series.

Transparency, Openness, Visibility, Accessibility.

Now, these terms might scare the begeebers out of anyone concerned with data security/data protection and such. Though and might contribute to transparency, it is not to say that artifacts have to be visible and accessible to everyone in order for them to be transparent. These nuances matter. Teams will learn and adapt what levels of visibility, openness, and accessibility work best to run production smoothly yet securely.

Now with Scrum, it is that everyone shares the same understanding of the artifacts in play. They are there to create transparency over (potential) value, complexity, and the use of the actual product. When their state is abysmal, stability, and reliability plunges. The ability to make decisions effectively deteriorates. Value goes down the drain.

Image for post
Image for post

Events

Scrum Artifacts are living documents. All Scrum events are purposed to ensure the artifacts are well tended to. In addition to these, the Scrum Guide explains that Scrum Teams generally spend 10% of a Sprint refining the Product Backlog. These events (and Backlog Refinement) I will cover continuing this series.

Image for post
Image for post

Monitoring Progress

Scrum Teams are mastering the of being ual. Monitoring progress in Scrum is primarily done through direct of the actual Increment. Sprint Reviews serve to monitor progress towards Sprint Goals. During these reviews, progress becomes transparent to Stakeholders.

The Development team monitors progress only to project the likelihood of achieving the Sprint Goal so they can adapt accordingly throughout the Sprint. They likewise do this by making actual progress on the increment transparent to each other on a daily basis.

Although Scrum Teams may engage in other projective practices, like Burn-Up/Down charts, the use of these should not replace the need to inspect the actual progress of actual work. Let’s be honest, they generally end up doing that, resulting in decisions being made based solely on a mirage.

Impact

Many might frown upon Scrum’s lightweight Framework at first.

I‘ll go ahead and categorise my younger professional self to be one of those corporate bureaucrats who ran out of places to hide. Personally, coming from a background in software and business architecture, I used to (and secretly still do, ) love chewing through and spitting up all sorts of artifacts. Calmly running through and munching all the chewy stuff is relaxing. This might be the case for you too, having come this far into the series.

Scrum is something to . I now value Scrum’s artifacts so much; I could hardly imagine myself doing without.

Thanks for staying tuned.

The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.

Next Episode:

Image for post
Do you want to write for Serious Scrum or seriously discuss Scrum?

Serious Scrum

Content by and for Scrum Practitioners.

Sign up for Serious Scrum Newsletter

By Serious Scrum

In this periodical newsletter we will inform you about the most recent developments and accomplishments of Serious Scrum. THE reference in the field of Scrum and related practices on Medium. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Sjoerd Nijland

Written by

Scrum nerd (PSMIII, SPS, PSPOII, PSD, PSU), Agile geek (PAL), Serious Scrum founder

Serious Scrum

Content by and for Scrum Practitioners.

Sjoerd Nijland

Written by

Scrum nerd (PSMIII, SPS, PSPOII, PSD, PSU), Agile geek (PAL), Serious Scrum founder

Serious Scrum

Content by and for Scrum Practitioners.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store