Writing good quality Product Backlog Items

Observing value two from the Agile Manifesto

” … we have come to value … Working software over comprehensive documentation”,

Product Backlog Items (PBI) are often the only mandatory documentary asset produced by a Scrum team. As such there is a lot riding on their quality.

In an effort to make a PBI understood by all stakeholders, it is good practice to express the requirement of a PBI in User Story format:

As a <role>, I want to <capability>, so that <receive benefit>

This encourages limiting the PBI to one testable action. Where a product provides multiple actions it is best broken down into individual stories for each action, e.g. Create, Read, Update, Delete (CRUD).

The User Story, should be accompanied by two or three Acceptance Criteria. These can be functional or non-functional and, written in Gherkin language will be easy to automate.

Given <precondition>, When <action>, Then <testable outcome>

A final component of a good quality PBI is a Definition of Done, an agreement between business and development for when a PBI is complete and ready for production. A simple checkbox is effective. Your organization may maintain DoD at iteration or even product levels too. If this is the case then there should be no duplication.

in a 2003 article on xp123.com Bill Wake coined the INVEST acronym. In the same article, Wake also encourages to use the SMART acronym for creating effective goals.