“If you can’t write it down, nobody can agree to it.”

 

high-quality product backlog items (PBIs) is key to a smooth development process. PBIs are written tickets or tasks that articulate the requirements for different parts of a software solution. They describe what the product owner wants, provide specific direction for what developers should build, and set a standard for QA to test against.

When you have high quality, clearly written PBIs you can put them into a task management system (like JIRA, TFS, Trello, etc) and assign them to team members. With a controlled amount of communication (e.g. sprint planning, daily standups) your team can produce work from these PBIs. Most importantly, when the PBIs are either reviewed with a customer or based on mutually approved planning documents, you can be sure that the work produced is what the customer wants. In essence, PBIs are a framework for translating customer requirements (whether expressed formally or informally) into actionable work items.

PBIs can take different forms depending on the project. For example, if you are building a piece of software from scratch, you might need a particular feature to work in a very specific way that is unique to your new product. Those details belong in a PBI. It’s the same if you are adapting existing software for a customer. For example, if you are integrating an eCommerce application with Salesforce, you may be providing direction as to how sales data should be transferred from a web store to a Salesforce organization. Those details belong in a PBI. In both cases, you must articulate these needs in a clear and specific manner so that they can be understood by all the participants in a development process.

 

3 Key Parts of a PBI

             1. User Story

               2. Acceptance Criteria

               3. Tasks

 

Different development management systems create and organize work tickets in different ways. However, regardless of platform, most PBIs have similar elements. The first is a “user story” often expressed in a statement like:

 

 AS A (type of user) I WOULD LIKE (to take an action) SO THAT (the goal the user is trying to accomplish)

As a customer, I would like to add items to my shopping cart so that I can purchase them during checkout.

 

Notice that the PBI being described by this user story isn’t the entire checkout process, it’s the action of adding items to a shopping cart to be stored for checkout. This is reinforced in the Acceptance Criteria, which are the criteria by which this PBI will be evaluated for completion during testing.

 

PBI: Products Can Be Added to a Shopping Cart

User Story: As a customer, I would like to add items to my shopping cart so that I can purchase them during checkout.

Acceptance Criteria:

  • A customer can click an Add to Cart button on all products.
  • When Add to Cart is clicked, a Shopping Cart icon in the upper right of the page flashes for 1 second.
  • When a user clicks on the Shopping Cart icon they see a list of saved products and an option to begin checkout.
  • The list of products should be at a stable URL pathway that includes their username and ends in /shopping cart so that it can be bookmarked.

 

These Acceptance Criteria must be detailed enough that a developer can map out the tasks necessary to accomplish the feature, and the tester can evaluate whether it is acceptable. The level of detail here varies,  it depends on how specific the needs of the PBI are and how complex the website, application, or integration.

 

The final piece of a PBI, alluded to above, are developer tasks. The goal of the user story and acceptance criteria are to take the ambiguity out of the ask so that it’s as clear as possible what the developer should build. The developer should add to the PBI the specific, technical tasks necessary to accomplish these goals. In many systems, they also estimate the time to accomplish them, but we’ll leave that aside for the moment.

 

PBI: Products Can Be Added to a Shopping Cart

User Story: As a customer, I would like to add items to my shopping cart so that I can purchase them during checkout.

Acceptance Criteria:

  • A customer can click an Add to Cart button on all products.
  • When Add to Cart is clicked, a Shopping Cart icon in the upper right of the page flashes for 1 second.
  • When a user clicks on the Shopping Cart icon they see a list of saved products and an option to begin checkout.
  • The list of products should be at a stable URL pathway that includes their username and ends in /shopping cart so that it can be bookmarked

Developer Tasks:

  • I can’t fake these
  • Help
  • Someone help

 

So, why put all this effort into writing the perfect PBI? The secret is in the levels of communication. If you can express your need in the form of well-written user stories, acceptance criteria, and developer tasks, there is an excellent chance that the consumers of different types of information are on the same page.