PRINCE2® replaced the traditional Work Breakdown Structure with the Product Breakdown Structure. This may seem like a modest change, but we think of this as a major and necessary shift in project focus: Rather than focusing on activities and a breakdown structure with simple tasks as its leaf nodes, we shift our focus towards products and deliveries as leaf nodes. This we regard as a major improvement in project theory and practice, aiming to reduce and ultimately remove sub-optimization.
If Project Plans, budgets, management, and reporting all concentrate on the main thing - running software of high quality - there will be less room to cultivate ‘silos’ in the project organization. To exemplify such silos, we mention the “perfect” Project Management Office producing beautiful reports (and spending up to 4% of the Project Budget on project control), the Product Managers and Architects grooming their backlog items way beyond necessary standards, or the Test Managers producing waterproof test plans and procedures (and blaming the other departments for all sorts of delays). Such silos may arise from exaggerated focus on project artifacts such as reports, test plans, backlog items or architecture documents. Focus should be on software quality, not the quality of a given artefact.
The most significant symptom of sub-optimization is ‘over-reporting’, as when management on different levels requires written reports, be it on mail or PowerPoint, weekly or even more frequently. All communication in agile software development initiatives should employ face-to-face talks, the only exception being routine reports to the Project Board at the end of each Iteration. The volume and quality of the Stories delivered in each Iteration speak their own language, and this is the key to reporting and progress monitoring. All resources and activities should contribute to secure these most central deliveries from the initiative.
For agile software development initiatives, ACE recommends a Product Breakdown Structure as illustrated below.
In the first level, we have the Business Objectives, and first and foremost the Effect goals (expected outcomes, or impacts). These are quantified goals, describing what the receiving organization wants to obtain by implementing the deliveries from the software development initiative. An example could be ‘The case handling efforts should be reduced by 30%’. If done correctly, these Effect goals should be tightly connected to the Business Case and optimally the Benefits Realization Plan, in such a way that each Effect goal is delegated its own responsibility for quantified benefits.
In the second level, we have Epics. An Epic is a high level user story, describing a set of software features that combine to fulfill a certain goal for a certain stakeholder. An example could be ‘As a case handler, I want the case handling system to be fully integrated with the archive, so that I do not have to work in two different systems simultaneously’. This level of Epics is a strong concept in Project and Release planning, especially if we utilize Story Points and Benefit Points to distribute cost and benefit parameters from this level and further down the hierarchy in the Product Breakdown Structure.
In this way, ACE has cultivated the concept of Product Breakdown Structure, by introducing both cost and benefit values on the nodes in the structure. If the cost and benefit values are inherited from, and continuously aligned with, the business case, we arrive at a third generation of Breakdown Structures. The concept of Value Breakdown Structure was introduced by Stephen Devaux in 1999*, and we consider the approach presented in ACE as a reinforcement of this concept.
We may visualize the 3 different perspectives on software development initiatives in the following way:
The relations between Effect goals and Epics could be many-to-many, in that a certain Epic could partly or fully satisfy one or more Effect goals. The normal situation in software development initiatives is that you have a few Effect goals, but a number of Epics at the next level.
The third level in the Value Breakdown Structure is the Story level. The Story is the unit that is handed over for Construction in the system development value chain. Optimally, it should be small (50 – 150 construction hours to meet ‘Definition of Done’).
The relationship between Epics and Stories is one-to-many, as in a tree structure. Together the Epics and Stories constitute the Product Backlog. For the Product Manager and Project Management it is sufficient to focus on these levels. The Development teams will take care of the detailed structure beneath the level of Stories. This happens during Iteration Planning, where selected Stories are broken further down into Iteration tasks.
* Stephen Devaux: "Total Project Control: A Practitioners Guide to Managing Projects as Investments". CRC Press 2014