What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 

By writing it this way you can clearly see what it is that is trying to be achieved, you also know who it is aimed at and what the benefits are.

Conditions of Acceptance (COA) - These are effectively criteria that must be met for the PBI to be considered as done. They will often drive test cases, as well as the QAs own mind and inquisitive thinkings.  The COAs can b written in Given When Then format, or they can drive the teams in coming eup with their own GWTs which are then reviewed by the Business Analyst or Product Owner.

Every PBI will be sized in a sizing session, this is where the team sit down with the product owner and business analyst and will have a look at the title, description and the COAs and then come up with an arbitrary size based on how big they think it is. 

The following sizes are used (fibonacci sequence):

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,

Every team will size a PBI different, however, they will have their own scale so a PBI that is a 2 for one team may be a 3 or even a 5 for another team, many factors will play in to a size of a PBI, ranging from complexity, to teams knowledge of the systems (another factor that will change the size of a PBI from team to team). 

Sizing a PBI will give a team an idea of what they can fit into a sprint, each team will have a velocity of what they normally achieve in a sprint, and this gives the business an idea of when they can expect certain features/PBIs to be completed. Again, this is why every team will size a PBI differently, and this leads into the amount of story points that a team can do in a sprint, so whilst team A might be able to complete 20 story points in one sprint against another team that can do 15, it's not necessarily saying that team A are completing more work...

Hopefully this has given you an idea of what PBI is, it is essentially an item of work that will have a number of team (QA and Dev) tasks against it, that the team will complete during a sprint.