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.