Product Breakdown Structure

Use the Product Breakdown Structure (PBS) to visualise all the components that make up the product

The Product Breakdown Structure (PBS) is a communication & planning tool. The Product Breakdown Structure is an excellent way to visualise what is needed for the end product without going into too much detail. As it is a diagram you can use it to communicate across language barriers. When used in conjunction with the “Product Description” you have a powerful means of communicating what the project is expected to deliver. This can be used for guiding the teams in defining the detailed requirements.

Creating the Product Breakdown Structure is an iterative process

The process of breaking down the end product into its component parts is iterative and works in conjunction with developing the component product descriptions, the Product Flow Chart (also known as the Build Road Map) and the User Scenarios and Acceptance Tests.

If the term “Product” is a little confusing then substitute it with a term relevant to what your are doing. A person working on an ERP system may substitute “Product” with “ERP System”. A person building a hotel may use the term “Hotel Complex”.

For those working with Agile software development the “Component Product” is the same as an “Epic”

What does a well-formed Product Breakdown Structure do?

  • Gives a visual view of the component products / behaviours that are required for the project product
  • Breaks down a complex product into more manageable component products
  • Turn complexity into simplicity.
  • Improves communication

  • What can we use a well-formed Product Breakdown Structure for?

  • By visualising the product and its component products we are able to improve communication and reduce misunderstandings.
  • Break down component products into sub-components so that we can identify what is of value early on in the development process and what can be defined and developed later in the development process. This supports the agile manifesto principle of “Simplicity–the art of maximizing the amount of work not done–is essential”.
  • In conjunction with the Product flow Diagram, identify in what order component products should be built. This will enable the team to progressively develop the component product descriptions.
  • Managing the grouping of User Scenarios and Acceptance Tests and allowing for rolling wave development of User Scenarios and Acceptance Tests rather than developing everything up front.
  • For eCommerce software solutions the numbering (configuration id) system can be adopted by the UX and design teams to clarifying how wireframes and designs fit into the bigger picture.
  • With rolling wave planning it is easier to add / remove sections and still keep the configuration identification valid and understandable.

  • Generic Product Breakdown Structure can be used to improve planning and communication

    Image displaying the Product Breakdown Structure

    E-Commerce Product Breakdown Structure can be used to improve planning and communication

    Product Breakdown Structre