Product Backlog Items


Agile Fundamentals Online Learning
What is Scrum?
Scrum Roles

The course is part of this learning path

Start course

This Course provides an overview of the popular Scrum framework, as well as helping you understand what a product backlog item should look like, and why incremental delivery is such a powerful tool.

Learning Objectives

The objectives of this Course are to provide you with an understanding of:

  • What Scrum is
  • The roles and responsibilities of the different Scrum roles
  • What the different Scrum artifacts are
  • What a product backlog item should look like
  • How to deliver incrementally
  • What the Scrum events are

Intended Audience

This Course is suitable for anyone with no prior knowledge of Agile who is considering, evaluating or involved in a move towards working in (or with) an Agile environment.


There are no prerequisites for this Course, however, participants should be familiar with the content and rationale in the Agile Manifesto (


We welcome all feedback and suggestions - please contact us at if you are unsure about where to start or if would like help getting started.


So you want to work in a scrum team and you know that scrum teams use product backlogs to capture all of the requirements. But what does an individual product backlog item actually look like? There isn't really a simple answer here, as every team needs to figure out their own product backlog, but a common way of creating product backlog items is to create user stories. User stories are transparent and easy to understand, and they're created by the product owner. In this video, we'll discuss a quick and easy method you can use to create user stories using two simple models together. First up we have the three Cs, which is cards, conversation, and confirmation. And then to determine if those cards are actually ready to be used, we can use the INVEST model.

Let us talk about the first of the three Cs, the card. It doesn't matter if cards are made physically on sticky notes, or written up on a board, or on a digital tool. The important thing is that they are simple and easy for anyone who reads them to understand. Cards should always ask and answer three core questions: Who is the user? What do they want? And why do they want it? For example, as an employee, I want a system to book leave so that I can spend more time with my family. This story gives us a simple explanation of the requirement, but as you can clearly see, it doesn't provide specifics of exactly what the solution should look like. In other words, the user story tells us generally what the solution needs to do, but not exactly how it should do it.

Okay, now that we've got a card, it's time to move onto the second C and have a conversation. The conversation should be ongoing, and happens between all stakeholders from when a development team first sees a user story during the development process through to the sprint review and demo, everyone involved needs to be talking. This ongoing conversation helps avoid misunderstanding and lets everyone collaborate more easily. Last up, the development team have realised the user story and delivered the increment, and it's time for the final C to be used, confirmation. It's up to the product owner to confirm that yes, the increment meets the requirement laid out in the user story, or no it doesn't. If it hasn't, the story may need to be worked on, and if it has, the team will be able to move onto new work.

Everyone in the scrum team should know what done looks like, so getting the product owner's confirmation shouldn't be difficult. So now you know how to create user stories and how to use them in an Agile environment using the three Cs. But how do you know if a user story is actually ready to be used? A simple way to figure out if a user story is ready to be pulled into the sprint backlog is to use the INVEST model. INVEST is a simple acronym, so let's run through it quickly.

So the first one, independent. Stories need to be independent of each other. They cannot all be related to one another, as we don't want to fall into a scenario where we're blocking each other in a team. All of the user stories need to be able to be worked on potentially even simultaneously. User stories need to be negotiable. This means they are not demands or contracts from the product owner to the development team. Instead, they should capture the imagination of the person who's to work on the user story, and allow them to interpret and discuss how they want to deal with it.

Obviously they need to be valuable. We don't want to be creating any kind of product or service that's not valuable for any of the stakeholders involved. They need to be estimable, so at the point that you're going into a sprint, teams can estimate how much effort each user story will take to action. It's important to have some way of understanding the capabilities of your team, and how much they can achieve within a sprint so you can estimate how much effort any given user story will take to action.

They should be small. It's generally a good idea to have really small user stories, because if they're nice and small and compact, they're probably gonna be estimable and achievable in a single sprint. The smaller the better.

Last up for this we should be able to know how we can test the deliverable, and that it does what we think it should do. And that's it for this video. If you want to capture your requirements for a product backlog, you can use the three Cs and the INVEST model to create simple and transparent user stories which give your development team the freedom to work in a self-organising and cross-functional way.

About the Author
Learning Paths

Tony has over 20 years’ experience in Business Development, Business Change, Consulting, and Project/Program Management working with public, private, and third sector organizations.

He has helped organizations to design and create processes and procedures to align ways of working with corporate strategy. A highly motivated and detailed solution provider, utilizing a wide range of methods and frameworks to provide structure whilst promoting creativity and innovation.

As a confident and self-motivated professional with excellent communication skills, Tony is able to bring people together and get them working as a team quickly.

Tony is an Agile and Scrum trainer with a vast knowledge spanning IT Systems, Business Change, Program and Project Management. With excellent presentation skills and a solid background, he ensures that all clients gain maximum benefit from his training. He has successfully guided those new to the industry through their initial training, helped experienced staff as they progress in their careers, and worked at the director level advising on best use and practice, as well as tailoring courses to fulfil the exact needs of clients.