This is another post resulting from my recent review of the notes I made when taking my CSM course. I love a good mnemonic. There are plenty of words that I can only spell by remembering some strange sentence. I especially like it when a mnemonic relates to the data that one’s trying to remember, and INVEST is certainly that.The Product Backlog Item (PBI) is one of the most important artefacts in Scrum and Kanban. I’ve seen varying qualities of PBIs over the years; from tickets with half a sentence to tickets with full user stories and acceptance criteria, and even Given, When, Thens. As Scrum Masters it’s important that we teach / coach our teams and maybe even the wider business the quality of PBI that an engineering team needs to be able to provide a deliverable in a timely and cost-efficient manner.


The PBI should be self-contained, in a way that there is no inherent dependency on another PBI.

To have tickets that are completely independent you may need to consider the prioritisation of work so that tickets don’t have any prerequisites by   the time they get pulled into the sprint. If a ticket is dependent upon something else then the team needs to create tickets for all the dependencies that they can identify and introduce these into sprints prior to including the final desired ticket.

You may find that you need to introduce tickets over a number of sprints in order to complete one piece of work. To make sure that the team doesn’t adversely affect the product during these sprints that the planning for each sprint and each ticket has considered the impact on the product of having a partially finished feature present. You may find that you have to keep the area being developed as unreachable, which would unfortunately make it of no immediate value. A better approach would be to work out how the feature can be reduced so that it is usable by the end user from the start, and gradually becomes more useful.

You may find that you need to employ the other items on this list in order to meet this one.


PBIs, up until they are part of an iteration, can always be changed and rewritten.

This is something that I see a lot of people struggle with, both inside and outside of the team. With traditional product management techniques your customer would have to provide their specification up front, and although changes were possible they would incur an additional cost and most likely happen as another phase at the end of the project. This has conditioned people to be wary of making a change once they’ve spoken to the product owner / project manager about their requirements. In agile, we must be explicit in our explanations to our customers that if their requirements have changed prior to us starting work then there is no cost to them so long as they tell us.

If we fail to communicate that change is built into our system then we are failing our clients, and removing one (if not all) of the benefits of agile. Every time we speak to our client we must remind them that our work is negotiable up until the start of the sprint that it is included in. This gives the client an opportunity to speak. After a lifetime of conditioning it is going to be hard for a client appreciate how much we mean this. By asking them if there is anything that they want to change we are giving them permission to tell us that they want to change something.

Internally, anyone can change anything along the way. If the engineering team have learned something that could benefit the project then they are obligated to act upon. For instance, they may realise that a particular route they’ve been taking is going to end up being difficult to maintain in the long run and so need to change it in order to prevent a build up of technical debt.


A PBI must deliver value to the stakeholders.

I love this as an ideal, but I struggle to meet it (and I’m sure that many teams do). I’m not sure where the responsibility for this failing is. In part I think that businesses can consider multiple features one feature. I’ve seen requests for a single web page that could have easily been broken down into multiple sections, with each part delivering some value. Perhaps it should be the PO before the team has a look, or maybe the SM after the team has looked at it.

We need to educate our stakeholders what can be considered value. Again, this is a conflict from the more traditional project management practises. People are used to describing the end goal, and not used to describing the steps that they would like fulfilled in order to achieve that end goal. A game of Whys can help people to think at a lower level. Of course, we must be careful that this doesn’t turn into telling  the engineering team how to engineer the solution; it must purely  be an exercise of breaking one large problem into a group of smaller problems.

I understand that it can seem scary to suggest playing games when working with another company or department as we’re afraid that it won’t appear to be professional. However, game playing not only helps to create bonds between groups that don’t typically interact with each other, but it can also get to the heart of the problem that the engineers need to design and build a solution for. We need to overcome any concerns that we may have regarding structured game playing. I’ve heard many people complain that even their clients don’t know what it is that they want (there are even memes out there to capture it). So if we want to help our clients firm up their requirements then we need to try alternatives that aren’t from a traditional project management perspective.

If you consider a spike a PBI then I think that you  can still achieve this principle. The stakeholder for a spike should be the team, and the value should be that the team has more knowledge of the area that was researched for the spike and are ready to tackle that problem and deliver value to the wider business through their solution.


You must always be able to estimate the size of a PBI.

This has to be something that is considered a marker of a more mature team, and that they have a good support network. When a team is new or recently formed it is going to be a challenge for them to work out how long things are going to take them. They may be unfamiliar with the product that they are working on or with. They may not understand the levels of ability within the team. All kinds of uncertainty may exist. Teams who are having difficulty with estimation need to identify what exactly these difficulties are and how they are going to address them. If the problems are internal to the team then you’re in for a much easier ride than if the problems are external and coming from the team’s client.

Overcoming internal problems will most likely involve training from others who have been there longer, investigation in the form of spikes, communication with other teams, and coaching from the agile professionals in or out of the organisation.

Overcoming external problems will be a little trickier. As always, one of my default stances is to turn to game playing. Never be afraid, nor underestimate the amount of value games can bring. Of course, your problems may be because of supplier problems or the ilk. If something is out of your control or ability to influence, then the team must refuse any PBI to come into the sprint backlog until all of it’s dependencies have been met so that it is fully estimable. If your estimation is not possible due to external reasons, then the PBI is not ready to be worked on.

However, all of the above being said, estimates are just that. Never hold anyone to any estimate that they make. Do question your team why estimates are massively off and learn from it, but don’t think that any human can ever accurately determine how long a ticket will take or how hard they will find it. I’ve seen “an hour’s work” take a month. We learned a lot from it and moved on. The fear of any engineer in this situation is blame or punishment so our biggest challenge in Estimable is reminding everyone that it is only an estimate.


PBIs should not be so big as to become impossible to plan/task/prioritise with a certain level of certainty.

This is one of the hardest things that most teams have to tackle. In my experience teams find it difficult to break down tasks into smaller ones for many reasons. The most common that I’ve found is being unable to see what value is delivered in such small pieces of work. Once again, we’re seeing the poison of previous experience with waterfall projects taint a person’s understanding of what is valuable.

At this point we should turn to our mantra of minimum viable product. Is there some work behind the scenes that we can do that can prepare us for doing the next piece of work? Then do it as that adds value to the project. On top of that we can add either more behind  the scenes value or start to expose this work to the end consumer. Does that form you’re about to show need to have everything that you want it to have by the end from day one? Unlikely. Instead, put on the fields that matter the most to your client. Maybe you have a user details form and all you need to begin with is the user’s name and email. Some day it will have the ability to change the password, add different addresses, and other account functionality. For now though, just having the name of your user and a way to contact them is enough. As SMs we need to encourage our teams to stop thinking about the big picture, and help them understand what the business really needs to make a little bit more money today than it did yesterday. Tomorrow you can worry about making more money than you did today.

This goes beyond software development. Any project can be (and usually is) thought of in stages. Each stage allows a team to check their work and reevaluate the next stage. In waterfall projects it’s at these points we tell our clients that it’s going to cost X more and take Y longer. With agile, we’ve made a promise about the cost and delivery date, so at these points we talk to our clients about which features it is that they can descope in order to ensure that their deadline and budget is met. MoSCoW prioritisation is really good for this, but I’ll write about that another day.


The PBI or its related description must provide the necessary information to make test development possible.

There is plenty out there about the benefits of testing one’s software, so instead of reiterating the same arguments, I’m going to think about this in a paradigm away from software development.

Requirements gathering is an important part of any project. A friend of mine recently replaced their bathroom suite. They specified that they wanted a 1.5m long shower to their fitter. When they received their quote it showed the requirement was for a 1.2m long shower. My friend assumed that this was a misprint, said nothing, and work commenced and completed shortly afterwards. When my friend realised that this mistake was not just a typo she had to make a compromise with the fitter. The fitter agreed to change it so long as my friend paid the difference for the materials. This mistake cost them both money. The test here was for my friend to check that everything detailed in the quote was correct. My friend failed to do so because she thought that it would show a lack of trust. Testing makes sure that everything is correct so that the next stage can start with minimal risk, and ensures that no one is wasting time or effort.

We Can’t Do It!

If you’re struggling to manage any of these within a sprint then it’s probably worth thinking about changing the length of your sprint. I’ve often seen teams really struggle to keep the above principles within a two week sprint, but feel completely powerless to do anything about it. This often comes from a blind spot about the length of their sprints. Sometimes that’s because it doesn’t occur to them to change it, and other times it’s because it feels like management has imposed an unwritten rule about it that they can’t change. If your team is struggling with any / some / all of these principles then talk to them about changing the sprint length in either direction. Sometimes the biggest part of empowering a team is reminding them that they have the power.

Originally Posted at

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.