Scrum artifacts — gnome-proof armor, fire sword and a list of product features
The term artifact continues to be an integral part of the gaming world to this day. The word is well known and associated by enthusiasts and fanatics of The Witcher or faithful readers of Tolkien’s novels. It is usually the first avenue to which our thoughts, animated by the sound of the word artifact, run. However, before the avid ‘gamer’ sits down in their ‘Diablo’ gaming chair, before they bring their digital hero to life, completely sinking into a cybernetic world of magic, transcendence and flux, a team of savvy developers, along with a Product Owner and Scrum Master, must deliver this product, or in this case a game, to market. To do this, they certainly won’t get past Scrum and the artifacts nested within it.
Artifact according to Wikipedia and dictionaries
Artifact (Latin arte factum ‘artificially made’, ars accusative arte — art, technique; factum from facio, facere ‘to make’) — among other things, an object, event, etc. that is an artificial creation, i.e. the result of human activity, not existing in nature.
Following the definition further, we can see that an artifact is anything that is created by our work, whether physical or mental, that is the work of the human mind and human labor as opposed to the creations of nature.
Scrum is a framework, not a methodology!
Scrum, which is a framework and not often mistakenly called a methodology, is very much like the definition above.
Scrum artifacts are all the tangible products of the scrum process, being the elements that represent work or value, allowing for transparency and enabling inspection and adaptation of the process.
Scrum artifacts play an important role in building a picture of the Scrum team’s progress. In addition, they all need to be designed in such a way that key information regarding, for example, the scope of work, is clear and understandable to all. Scrum artifacts are open to all participants, characterized by total transparency and the absence of any levels of access or control.
Ken, Jeff and their Scrum Guide
Let’s take a peek and see what the Scrum Guide tells us about artifacts. Its authors Ken Schwaber and Jeff Sutherland include:
- Product Backlog
- Sprint Backlog
- Increment (product increment)
So, don’t be fooled into thinking that the Definition of Done, Definition of Ready, Burndown chart, Burnup chart and other charts such as the Gantt chart, which are very much the result and outcome of our work, are Scrum artifacts, because according to the Scrum Guide authors they are not.
They are simply other reference points that the team uses to plan and monitor their work.
This does not mean they are less valuable, they are just different. They are by-products of the work done by the team. Scrum artifacts, on the other hand, are where the team negotiates its direction, strategy and tactics.
What are Scrum artifacts?
Scrum is based on small teams made up of cross-functional members who can self-organize to get the work done. For this to happen, the Scrum team must have a shared understanding of the work to be done. This is where Scrum artifacts come in.
Scrum artifacts keep all team members coordinated as they work towards the sprint goal. Even when big or last-minute changes occur, Scrum artifacts evolve to capture (through Scrum meetings and using tools such as Scrum boards) the key information the team needs at specific checkpoints to get to the finish line.
Three essential questions
I think it will definitely be easier for us to understand this by knowing what question each of the three Scrum artifacts answers:
Product Backlog: What will the Scrum team work on in the next sprints and what makes up the product according to current business knowledge?
Sprint Backlog: What will the Scrum team work on in this sprint and how will they deliver it?
Product Increment: what will the Scrum team have done by the end of this sprint and how will they know it is ‘done’?
Artefact №1 — Product Backlog
Product Backlog is a list of ideas, functionalities, technical requirements, bugs, changes, etc. These changes may relate to extended features, fixes or technical work necessary to maintain the functionality and competitiveness of the product.
Most importantly, this is the only source of requirements, nothing else is taken into account when planning a sprint, if it is not in the product backlog then ‘THAT’ something does not exist.
Any team member can add new items to the backlog, but only the Product Owner decides the order, he determines which stories are most important at any given time. For the Scrum team, these user stories represent the work that needs to be done. The product backlog collects all this potential work in one place to give everyone a common roadmap and set the direction for future work.
User stories at the very top of the backlog translate into the most business value, before being placed there by the Product Owner, they have been carefully analyzed, decomposed and estimated to make sure they can be completed in one sprint.
The development team can estimate stories at any time, but most often do so during Backlog refinement and sprint planning. The unique property of a backlog is that it is never finished, you can’t say I’m done preparing a product backlog, it’s always the case that as the work progresses new ideas emerge, some fall out, others come in and still others may be moved up or down. One Product Backlog can also be shared by several scrum teams.
Teamwork and Backlog Refinement also once known as grooming.
Maintaining an effective Product Backlog is a team effort. The development team works with the Product Owner to refine the backlog. Product Backlog Refinement can include:
PRIORITIZATION: As circumstances change, items in the backlog change in value and priority. Is the team prepared to work on the most needed items, given what they know at the moment?
ESTIMATION: During a sprint, the team may discover that estimates of which items should be prioritized were badly off. Before the next sprint, it’s a good idea to revise any estimates you arrived at using old models or data.
ADDITION: New user stories need to be translated into new backlog items. There may also be technical debts that the product owner does not see that should definitely be included in the backlog.
DEVELOPMENT: The more one understands about a backlog item, the closer it is to being ready for the Scrum team to take on. Do they understand the scope of the item, including the agreed definition of performance?
Scrum vs. cascade approach
Scrum, unlike the cascade approach, knows that gathering all the requirements at the beginning of a project is impossible. To keep the product up to date, you have to keep adapting to the market situation, so isolation from the outside world and inspiration is not an option. This leads to the Product Backlog becoming a living entity that is changed and optimized on a daily basis. Constantly evolving to reflect the needs and desires of the customer, it is a dynamic artifact — evolving as more users test new use cases and scenarios.
Backlog form and tools
The form of the Product Backlog can be varied. There are no specific guidelines when it comes to the form of the backlog. It can take different forms depending on the preferences of the Product Owner, the team or the organization.
It can be in the form of sticky notes, in an excel table or, most commonly, from a web browser. Some of the most popular tools include:
- Jira.com
- Asana.com
- Trello.com
- Monday.com
- Clickup.com
PBI, or Product Backlog Item
A single backlog item is called a Product Backlog Item (PBI). A detailed description of the PBI should be done shortly before the development work. Burning time on a detailed description of all the items in the Product Backlog is a waste of time, as quite a few of them will not be implemented any time soon, and their scope may still change many times.
A good Product Backlog should be DEEP
Roman Pichler and Mike Cohn of www.mountaingoatsoftware.com created the acronym DEEP to describe the characteristics of a good product backlog.
Detailed appropriately — detailed enough. The level of detail of a given PBI depends on the position it occupies in the list. The items at the top are ready to be addressed in the next sprint, those with the highest priority should be described in sufficient detail so that their scope is not in doubt. PBIs that are not yet as important may not have detailed descriptions and are lower in the product backlog.
Estimated — estimated in terms of labor intensity. Several available techniques can be used for this. The more detailed the elements of the backlog are, the more precise the estimate should be. Obviously, the elements at the bottom of the backlog are the most difficult to estimate, as we generally have the least information about them.
Emergent — meaning emerging; giving rise to constantly new, previously unpredictable features. As we have already mentioned the Product Backlog is not a fixed entity, it is subject to constant change and modification. The further we are in the project, the more ideas, solutions and new functionalities emerge. This forces the Product Owner to reorder or even remove some items from the list.
Prioritized — containing priorities; PBIs are ordered according to priority, the most important elements — those to be delivered within the next sprint are placed at the top, those at the bottom have to wait until the Product Owner decides to implement them.
Artifact 2 — Sprint Backlog
The Sprint Backlog is nothing more than selected elements of the Product Backlog that the team has collectively planned for the upcoming iteration and a plan on how to deliver them.
Who is in charge here?
It is worth mentioning that this artifact is managed exclusively by the developers. The Product Owner can negotiate its content, but on the condition that this does not affect the purpose of the sprint. The development team determines its capabilities — i.e. how many backlog items it can complete during the sprint — and estimates the corresponding number of priorities from the product backlog. These items are then broken down into smaller tasks that the team can start working on. As the team organizes its own work, the division of tasks is at the discretion of its members. By completing these tasks, the team moves closer to achieving the goal of the sprint and delivering an increment, in other words, a working part of the product that represents real value for the end user.
Nothing is fixed and the rest is still unwritten
Like the Product Backlog, the Sprint Backlog is smooth. As issues arise and priorities change, the development team adjusts the Sprint Backlog as needed. If tasks are found to be unnecessary, they are dropped. For example, if new information emerges during a sprint or the status of one of the user stories, developers need to update the Sprint Backlog. The update should take place once a day and a tool to track and monitor progress during the sprint is the Burndown or Burnup chart, otherwise known as a burnup chart.
The difference is that only the development team controls the Sprint Backlog. While the Product Backlog looks to the future, the Sprint Backlog provides an up-to-date picture of progress and work remaining to be done.
In the right direction
The Sprint Backlog helps guide the team in the right direction, is a signpost for them and often answers questions. How close are the estimates to the actual deliverables? Does the functionality promised by the scrum team meet the needs of the end users?
Artefact №3 — Increment
Step by step towards achieving the product goal
Increment is the most important goal of every Sprint. It is the sum of all completed PBIs from both the current Sprint and previous Sprints. Each subsequent increment must work and be ready to be handed over to the end user.
A product increment is the result of a Sprint. It represents a usable, potentially releasable version of the product. In theory, it requires no further development or testing, and the product owner can release the increment immediately.
It needs to be usable and effective
The key question to answer is whether the increment delivers enough new functionality to call it the next version of the product. Another thing to bear in mind is that not every Sprint has to end with a product release, but at the end of every Sprint a useful increment must be created.
Simply “Done”
In practice, a product increment must be “done”. If there is no convention defining what constitutes ‘done’, Scrum teams are responsible for defining it, as the increment must meet all the requirements of the so-called Definition of Done.
No Scrum No Fun
Scrum is a very effective and flexible framework that helps to concretise goals, measure progress efficiently, respond and not let go when changes occur.
When the whole team is involved in the transparency of their artifacts, everyone can contribute their technical knowledge in a helpful way and share their experiences, risks or concerns. Developers who feel safe talking about potential problems will benefit product owners who want to carefully manage their work and bring a good and attractive product to market.
