Scrum Artifacts – Explained in 2 minutes

Aleksandar Mohamed

5 min read

scrum artifacts

In the most basic form, an Artifact in Software Development is the essential information that the team needs to be able to complete a project. This is exactly the same in Scrum, which typically breaks down the Artifact principle into three separate main categories. These are the Product Backlog, The Sprint Backlog, and Product Increments. Each of these Artifacts has its own extensions and by-processes ( planning, development, reflection, etc.) but these three are the core Artifacts.

These three Artifacts contain the details of the project and product development – what needs doing and how it needs to be done. They are the guides to the whole process, to be followed by the complete team, who also have input into structuring them. They are also transparent go-to markers for progress.

Let’s look at the three. Firstly, the Product Backlog.

 

1. The Product Backlog

At the start of the Scrum method is the establishment of everything that the complete should be. The requirements, the function, the features, the idea, and the vision, which turn into task breakdowns. This is the starting point produced by the Product Owner after discussions with all stakeholders. Whilst it is not a fixed document and is likely to change and evolve along the way, it is nevertheless the point at which the journey begins.

This list of requirements is then prioritized, with input from the other team members, and managed and maintained during the Sprint and before the next Sprint cycle. The Product Backlog artifact doesn’t need to be heavily technical or detailed – this will come later in planning meetings. It is more like the points marking the journey stops on the map towards the final destination. And like all the best trips it should be a flexible guide rather than a set-in-stone list.

Think of the Product Backlog as if you’re planning a touring holiday for a group of friends. You know where you need to be at the end and when you need to be there. You’ve done your homework and read the guidebooks. You know what attractions and places you want to visit on the route and you have a reasonable idea of the most logical way of going about it. However, things will change along the way, other unexpected or unpredicted factors (weather, transport issues, fatigue, spontaneous drinking sessions, other members of the group wanting to see something different). 

If you deal with these flexibly and positively, you can actually have a better trip than the original plan. But of course, somebody still has to lead the way and make the plan in the first place or you’ll never set off.

 

2. The Sprint Backlog

Next up is The Sprint Backlog artifact taken from the Product Backlog. This is a plan of everything an individual Sprint should achieve. The whole team is involved in planning this Sprint Backlog and all agree what are the expectations, commitments, and timeframe. Each sprint is typically about 2-4 weeks. This sprint Backlog is the list of work that needs covering and completing is this time.

The development team chooses what exactly will be in the Sprint Backlog and the amount of time these tasks will take to deliver. This is therefore a much more detailed breakdown, which can be updated in the daily planning meetings during the Sprint. Tasks may be added or removed as well as adapted. The Sprint Backlog involves team responsibility and accountability and ought to be self-organized by the development team.

On our trip, this is the point at the end of each day when all the friends come together and decide the next destination, the travel plans, meeting points, places you might want to visit along the way, what you want to do when you get there, etc. Some people will want to visit the National Museum, others the bars around the old town – great form small groups work together and arrange a mutual meeting point later.  Everybody is happy doing their own favorite thing but you are still on the trip together. The next time you might form different groups.

 

3. The Product Increment

Finally, in each Sprint there is a Product Increment Artifact.  This is the result of the Sprint or what has been completed during the Sprint. It is also an assessment of the value these incremental gains bring to the project and how much closer the team is to the goal. These increments are often tested and approved tasks that can be released.

Increments, being small steps but completed small steps that lead towards the end.

Back to the trip – we are at the stage where we can tick off that city or country. It’s done we’ve been there and done it, everybody is happy, we’ve banked that experience. So we move on to the next.

 

Conclusion

Scrum artifacts serve a purpose and that is making the whole Scrum process efficient and effective. Everybody in the team has input and an active role. They all play a part and they all know exactly what their part is. The artifacts are visible, transparent guides that light up the way. No one is lost, no one is left behind and the path ahead is clear. Placemarkers for teams.

Subscribe to our newsletter

Stay on top of your communication game

Customer stories, tips, and our opinions on everything in between - all in one place