Skip to main content
Do you need web development services?

Scrum Artifacts and how to ensure transparency

Let’s look at the Artifacts involved in Scrum – items or objects that provide Transparency and allow us opportunities for Inspection and Adaptation.

Product Backlog

The Product Backlog is an ordered list of all the features that might be required in a product. The Product Owner is responsible for the content, ordering and availability of the backlog.

The Product Backlog is a living artifact, that is, it is never complete. Items are removed from the backlog when they are selected for a Sprint. Items can be added to the backlog at any time, but are most commonly added during Backlog Refinement.
Initially the backlog holds only the best known requirements, but as the product and its environment change, items are added to the backlog.

The items in the Product Backlog are ordered by their priority. Higher ordered backlog items are usually clearer and better understood than items lower down the list. As items increase in priority, they are refined so that the Development Team have a better understanding of them.

The Product Backlog is an information radiator – a large, easy to see, display of data that is accessible to all. It allows individuals to see the upcoming features for a product and liaise with the Product Owner if they think an important requirement is missing. However, only the Product Owner can add items to the backlog.


Sprint Backlog

The Sprint Backlog consists of the Product Backlog Items selected for the Sprint, plus a plan of how to turn those items into an Increment.

During Sprint Planning, the Development Team decides which items it can implement during the Sprint, and these items are selected for the Sprint Backlog. The Development Team then formulates a plan on how to complete the work.

sprint backlog

As more information becomes available during the Sprint, the Sprint Backlog may change, with new items being added or unneeded items being removed. The plan to implement the items may also change.

The Sprint Backlog is owned by the Development Team. Only they can decide how much work can be completed in a Sprint and only they can change the Sprint Backlog.



The Increment is all the Product Backlog Items that have been completed during the current Sprint, plus all of the previous Increments. The Increment is a “Done” piece of software functionality that is potentially releasable to the customer. It is the decision of the Product Owner if the Increment is actually released or not. The Increment should allow the Sprint Goal to be satisfied.


Artifact Transparency

So that artifacts can be inspected, they must be transparent. This allows decisions based on the state of the artifacts to be made in order to control risk and increase business value. If artifacts are not sufficiently transparent, then they cannot be successfully inspected and risks may increase, costs may rise and decisions can be made incorrectly.

A good level of transparency has been achieved when the state of an artifact allows it to be easily inspected. This can be achieved by creating an open and blameless culture and ensuring that all members of the Scrum team are easily accessible. Stakeholders should be able to easily visit the Development Team in their office, as long as this doesn’t negatively affect the work of the team e.g. by stakeholders trying to add work to the Sprint without the consent of the Product Owner.

The Scrum Master works to ensure that all artifacts have the required level of transparency. They can do this by inspecting the artifacts, looking for patterns and noting differences between expected and actual results. For example, a Cumulative Flow Diagram can show where backlog items have been stuck in progress, causing a bottleneck. However, if a Scrum Master is made aware of an impediment, but this isn’t reflected in the cumulative flow diagram, this can indicate that the progress of a backlog item hasn’t been updated i.e. the Sprint Backlog doesn’t have full transparency.

Alhmodeus / CC-BY-SA-3.0


Scrum Events – Backlog Refinement

Backlog Refinement isn’t an official meeting as defined in the Scrum Guide, although it does state

The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team.

The meeting is held mid-Sprint, before Sprint Planning and the aim is to get the Product Backlog and its items into such a state that the highest priority items can be pulled into a Sprint. It ensures that the Sprint Planning is effective and efficient – team members can focus on selecting the PBIs for the Sprint, rather than trying to understand the PBIs.


The aim is to prioritise the Product Backlog so the items with highest priority are at the top and ready to be selected. Backlog Refinement also ensures that PBIs are of a good quality and are understood by the team. Ideally we want to conduct enough refinement so that we have PBIs to cover the next two Sprints. This ensures that even if the Product Owner is unavailable, or the Development Team has extra capacity, there are enough PBIs in a ready state.

Below are the steps that take place in the Backlog Refinement meeting:

product owner


Coming into the refinement meeting, the Product Owner should already have a good idea of which PBIs are the highest priority. Outside of the Scrum meetings they will meet with stakeholders in order to prioritise the backlog. They can use a variety of prioritisation techniques to achieve this, with assistance from the Scrum Master.



The Development Team must understand the PBIs so that they can successfully implement them. This can take the form of querying the Product Owner or the stakeholders. It may also require the team to go away and research a particular topic in order to improve their understanding of it. This research time should be included as part of the 10% Backlog Refinement time, to ensure that it doesn’t take over the time needed for development. Research tasks shouldn’t be added to the current Sprint, as they’re not adding any business value.



Once the team has an understanding of what a PBI requires, they must ensure it’s of a good quality by using INVEST. This ensures that an item is Independent, Negotiable, Valuable, Estimable, Small and Testable.

If the item doesn’t meet all of these criteria then it must be refined so that it does. This involves splitting the item into thin vertical slices that cover each of the architectural layers i.e. database, server, client.vertical slice

Each slice covers a level of functionality right through from the front-end to the back end. It might only offer one particular feature, but that feature is completely throughout each level of the architecture. Importantly, a vertical slice allows us to deliver something of business value.


Acceptance Criteria

Once a PBI is appropriately sized and understood, the team define acceptance criteria for it. This allows them to define when an item is Done.


planning poker



Bearing all of the above in mind, the Development Team can now estimate each of the PBIs that we’ve been dealing with (2 Sprints worth). There are a few methods for doing this, which you can read about in my post Estimating Product Backlog Items.


You may find that once estimation has taken place, the Product Owner revises his prioritisation of the items. That ‘must have’ feature might not be so important when he discovers how much effort is required to complete it.



The Backlog Grooming meeting ensures your backlog is ready to go when it’s time for Sprint Planning. Done correctly the output will be a prioritised backlog with items that are understood by the team, of an adequate size and estimated. This means the Development team can more accurately select the appropriate number of items for their Sprint Backlog. This in turn means they should have a consistent Velocity, which leads to more accurate forecasting.

Scrum Events – The Sprint Retrospective

The Sprint Retrospective allows the team to inspect itself and adapt the Scrum process for the next Sprint. The meeting is time-boxed to 3 hours and involves the whole Scrum team.

We look at how the last Sprint performed with regard to

  • People
  • Processes
  • Relationships
  • Tools

We also identify what went well and what could be improved. This items can also be ordered in terms of importance.

Finally, the whole team collaborates to create a plan for the next Sprint. This details how the improvements that have been identified, will actually be implemented.


The role of the Scrum Master is to see how the Scrum process can be improved so that the team can fully benefit from it. They encourage the team to improve their development processes so that they are more effective in the next Sprint.

Using what we have learnt from the Sprint Review and Retrospective meetings, the team can adapt the Definition of Done. For example, perhaps a stakeholder who turned up to the Sprint Review was colour blind and the team had not tested for sufficient contract on text colours. The Definition of Done can be adapted to the include accessibility testing of the subsequent increment.


Although it is one of the shortest Scrum meetings, it is also one of the most important. It allows us to utilise the empiricism that Scrum offers, so every Sprint we have a formal opportunity to inspect and adapt.

In subsequent posts, we’ll look at some of the techniques that can be used during the Sprint Retrospective in order to facilitate discussion and learning.

Sprint Retrospective technique – Stop, Start and Continue

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.


start stop continue

Start, Stop and Continue

In this technique, team members describe actions they think the team should Start, Stop and Continue doing.

Start items are those that the team haven’t done before but it seems likely they will be of benefit.
For example:

  • Show the software to the customer before the Sprint Review.
  • Ensure everyone has an equal amount of time to speak at the Daily Scrum meeting.
  • Include research time in PBI estimation.


Stop items are those which don’t add value or are inefficient.

  • Stop trying to use the latest, in fashion Javascript framework.
  • Don’t work on items that aren’t on the Sprint Backlog.


Continue items are those which we think have benefits, but haven’t yet become habit. Including them on the continue list gives us a reminder and ensure we do them in every Sprint.
Any of the previously identified Start/Stop items can go onto the Continue list. They are removed after a few Sprints, to ensure the list doesn’t get too long.


Selecting items

There are many ways in which the Scrum Master can ask for suggested items.

  • Simply allow team members to shout out the items.
  • Only allow particular items e.g. the Stop items.
  • Go round the team to ensure that everyone has the chance to put forward their ideas.



Once enough ideas are generated, the team should vote to determine which are the most important. This can take the form of each person voting for their highest priority item, or being allowed a certain number of vote e.g. 3, that they can assign to items as they wish.


The Subsequent Sprint Retrospective

At the next Retrospective it can be useful to bring along the list of items. The team can then determine if they have been effective in starting, stopping or continuing the items that were given the highest priority.



The Start, Stop and Continue technique is an easy way to generate actions during a Retrospective. It’s easy to grasp and you don’t need any special tools or software (although a physical board for displaying items on is helpful).

Sprint Retrospective technique – The Sailboat

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.


This technique uses a sailing boat as a metaphor for the team. The wind represents the things that are pushing the team forward, while anchors represent the things that are holding it back.

Using a diagram of the boat, team members use post-it notes to detail items in each of the above categories. They then stick them to the diagram in the appropriate place and read it out as they do so. You may find that common themes emerge, so related notes can be grouped together.

Once all the notes are posted, the team may choose to dot vote on those they think are most important. Usually each member has around 3 votes, which they can distribute however they wish.

The team then looks at the items under each heading. The ‘wind’ items are those that the team should continue doing. While the ‘anchor’ items should be addressed to remove the impediments. Perhaps ‘anchor’ items can even be transformed into ‘wind’ items?


Going forward

You don’t have to stick with the sailboat metaphor, there are many other objects you could use – cars, hot air balloons, a tree.

Sprint Retrospective technique – Timeline

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.


A timeline retrospective allows the team to inspect how well the Sprint went, over a period of time. First, you will need a set of axes that represent each day of the Sprint. If you imagine the diagram below, but without the coloured cards.

Adding cards

Each team member will have cards in the colours above and they write down the events that occurred, on the appropriately coloured card. They then attach the card to the board so that it corresponds to the time that it occurred during the Sprint.


Drawing Conclusions

The chart provides an excellent visual representation of the Sprint and allows the team to easily see what went well and what could be improved. It also allows us to discover if certain events lead to other events – perhaps a significant event lead to a series of problematic events. Or there may be a cluster of good events around a particular time period.

Either way, the team can discussed these points and learn from them.

This chart could also be compared to the burndown chart for the Sprint. Does the velocity of the team increase when it experiences good events?



Based on the discussion, the team should identify actions they can take in order to improve in the next Sprint.

The Agile Manifesto

In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over Processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.


The Agile Manifesto in detail

But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.


Individuals and Interactions over processes and tools

In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:

  • Creating a blame free culture
  • Ensuring individuals are able to speak up (see planning poker and silent writing)


Working software over comprehensive documentation

The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.

Comprehensively planning and documenting user requirements don’t give you anything of business value. It’s only when an increment is developed, that we get a return on investment.

However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.


Customer collaboration over contract negotiation

Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.

This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.


I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.

The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.

Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer.  If you ask them straight away, you can prevent minor issues from growing into large problems.


Responding to change over following a plan

In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.


Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.

If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.

We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.



When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:

  • Are my interactions with others adding value or are they causing impediments?
  • Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
  • Are we effectively collaborating with the customer?
  • Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?


Read the original Agile Manifesto, and get translations, here.

Scrum Events – The Sprint Review

The Sprint Review meeting takes place at the end of the Sprint. It allows the product increment to be inspected by the stakeholders and for the Product Backlog to be adapted by adding new items or rearranging existing ones.

The Sprint Review meeting is timeboxed to 4 hours, for a 1 month Sprint.

The meeting is attended by the whole Scrum Team, plus any stakeholders who have been invited by the Product Owner. First, the Product Owner explains which Product Backlog Items (PBIs) have been Done and which have not been Done.

Following this, the Development Team discusses what went well, any problems they had and how these problems were overcome.

Then the Development Team demonstrates the work that has been Done and answers questions. This is intended to be an informal demonstration, typically without the use of PowerPoint presentations. The presentation allows stakeholders to ask questions and give feedback on the increment.

sprint review meeting

During the Sprint Review, the Scrum Team should be able to demonstrate that the Sprint Goal has been met.

Following the demonstration, the Product Owner discusses the Product Backlog and may project likely completion dates based on the work completed so far.

The group takes a look at the overall timeline, budget and marketplace for the product, to give context for the next release.


The Scrum Guide also lists the following activities as part of the Sprint Review. In reality they are often moved to a separate event – Backlog Refinement.

  • The group collaborates on what to do next i.e. is the Product Backlog correctly prioritised or is it missing items?
  • A review of how changes to the marketplace have affected the work that needs to be completed next.

Definition of Done

When a product Increment is completed, we say it is Done. These are criteria that must be met before an increment can be released.

To know what Done really means, the Scrum Team must have a shared Definition of Done (DoD).

  • Separate teams that are working on the same product should share the same DoD
  • Separate teams working on separate products can have different DoD’s.

It may be that the organisation already has standards and policies which can be used as the DoD. But if these standards don’t already exist, then the Scrum Team must create one.


Example Definition of Done

  • Code compiles
  • Code Peer Reviewed by one other Developer
  • Tested by the Development Team
  • User Acceptance tested

Only when all of the above points are true, can the increment be called Done.

As the Scrum Team matures and adapts, it is likely that their DoD will change – it is likely to become more stringent, resulting in higher quality increments. See our teams’ current DoD.


Done vs Acceptance Criteria

Acceptance Criteria are used to define when a specific Product Backlog Item is complete – each PBI can have different acceptance criteria. While Done covers all PBIs in the increment.


Estimating Product Backlog Items

The items in the Product Backlog each have an estimate of the amount of work required in order to complete them. This allows the Backlog to be effectively refined and managed.

Why Estimate?

  • Allow the Product Owner to properly prioritise the Product Backlog – they can only do this when they have a proper idea of the relative cost of items.
  • It enables high level forecasts to be made. The proposed story points can be plotted in the burn down chart.
  • The Product Owner can make better decisions around scope and schedule – i.e. how important is that ‘must have’ feature, now that it’s been estimated to have a large effort required to complete it.

planning poker


When to Estimate

Our team performs estimation of Product Backlog Items during the Backlog Refinement meeting.

The earlier you estimate, the earlier the Product Owner has information that can be used to prioritise the Product Backlog. You’re not held to the estimate – if more information comes to light, or the item changes, then the estimation can also change. It may also be useful to confirm that estimations are still accurate when items are pulled into the Sprint Backlog. Even though the time between the Backlog Refinement Meeting and Sprint Planning may be short, there is still the potential for Product Backlog Items to change or be clarified.


Why we estimate in points

Story Points provide relative values for the level of effort needed to complete a Product Backlog Item. They take into account:

Effort – the amount of work to do.

Risk and Uncertainty – how much or how little we know about the item.

Complexity – how complex is the logic that we have to work out or the code we have to write.


The final estimate will be a combination of these elements.

Have you ever given an estimate in hours and then overrun, even if only slightly? I’ll bet the next time you gave an estimate, you added on some extra time as ‘wiggle room’.
The issue with hours is that they’re absolute and provide a false sense of certainty.

With story points, the estimates are relative, so we don’t say how long a particular item will take, just that it requires, for example,  double the effort of another item.

It doesn’t matter what values we use, as long as they are relative. So an item with 2 story points is double the effort of an item with 1 story point.


Deciding on a scale – Fibonacci

Although you could just use 1,2,3, etc, this doesn’t really reflect the increasing effort required as the numbers are close to each other. Instead, we can use the Fibonacci numbers, where each number is the sum of the previous two e.g.

1, 2, 3, 5, 8, 13, 21…

Don’t pick too many numbers for your scale, but you might also want to include a large number such as 987 or infinity, for assigning to items that are too large to estimate.


How to estimate

Before you can start estimating all your PBIs, you need to establish a base story. This is the most basic item that you can find on the Product Backlog and one that everyone understands well. This item is assigned a story point value of 1.

You can also assign points to a number of other items, in order to give a range of base stories from the simplest to the most complex – these stories can be real or can be created specially for this task.

Below I’ll detail some techniques that you can use to estimate.


Planning Poker

Probably the most popular technique for estimating is Planning Poker.

First, decide on a ranking scale for items – as previously mentioned, the Fibonacci sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings. You might also have cards with images, such as a cup of coffee – to represent when someone wants to take a break. Or something to denote when the discussion has gone off topic – I’ve seen a cartoon rat used, as in ‘going down a rat hole’.

The item to be ranked is read out to the group and each member selects a card based on their perceived estimation of the work involved. They must keep their card hidden until everyone has chosen. planning poker

Once every member of the group has selected a card, they are all revealed simultaneously.

If the selected estimates are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required estimate.

The same item is then estimated again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.

Alternatively the group may need to decide not on the ‘perfect’ estimation, but one they can support.


T-shirt sizes

As an alternative to using numbers, some teams use t-shirt sizes (S, M , L , XL) to estimate. This can provide an easier way to get started, especially if teams are afraid to commit to a number as they are even more abstract. However they can cause some issues:

  • They will need to be converted to numbers at some point if you want to plot burn down charts.
  • People may have different views of the relative effort required for a particular size. So, is a Large item twice as big, or ten times as big, as a Medium task?

t-shirt sizes



Each member takes a card representing a Product Backlog Item from the pile and adds it to the table. They position in it relation to how large they estimate the item to be – largest items go at one end of the table and smallest at the other end. The next person takes a card and places it on the table, in relation to all other cards. Or they can choose to challenge the position of an existing card. If they think it requires relatively more effort, it goes higher up the board, above the lower effort items.

Once all the cards are placed and the team are in agreement, the items are assigned an estimate using the Fibonacci scale. Starting at the smallest item, assign the card an estimate of 1. Repeat this for the next item up the table. Move up the table until you reach items that you would estimate as 2, then 3 and so on.



Once you’ve estimated the Product Backlog Items, the Product Owner can use those estimates to help them order the Product Backlog.

Over time, the teams’ estimates will become more accurate and they will have a better idea of what can be fit into a Sprint. This process can be sped up by utilising the Sprint Retrospective. The team looks at the estimates they gave for items on the previous Sprint and compares them to the actual amount of effort required. Using this knowledge, they can Adapt their estimation for the next Sprint.