Last year, I wrote a post about the Work Breakdown Structure (WBS) which opened let to many questions from my readers on how this differs between the traditional project management approach and the agile management approach. One reader in particular asked whether WBS is still valid in today’s project management industry, considering the vertality of the industry. I have summed up the discussions sent by mail, to make an open discussion on this topic in both the traditional and agile approach.
While WBS is importand as part of the scope baseline, it is true that it can be demanding in agile, especially because agile is founded on the tenets of acceptance to change. This is because, it is not necesarily the same activities that have been defined in the WBS that will be the same for deliverables that lie further into the future. The same deliverable may be delivered, but the activities may have changed in the course of the project.
The work breakdown structure (WBS) as used in the traditional planning, is good at identifying the actual tasks to be performed as identified in the project scope statement, easing tasks-assignment to team members, ultimately helping them to identify how their contribution fits into the big picture (PMI, 2006, pp. 5-7). This boosts team-morale and productivity. Additionally, its use to create a detailed action plan also contributes in safeguarding continuous progress towards earning value as each team member works on an assigned task. The structure acts as an assurance that the project scope is decomposed to cover all the necessary activities to be
performed in completing a deliverable (PMI, 2017, p. 158). This is important in the efficient management of resources, since it relies on a realistic project plan constructed from the structure, consequently enhancing accountability and transparency. Moreover, since it provides an overview of the activities required to contribute to the project’s goal, it reduces the burden of tracking how well each task matches the deliverables. Finally, the structural design of WBS in traditional planning makes it easier to identify potential risks, likelihood of occurrence, and how they can be managed.
The structure however, has a high risk of being too detailed at the work package level, due to poor definition of “done”, making it unmanageable. In such cases, it can easily lead to micromanagement by insecure management, causing resentment and distrust, inefficient resources use, and difficulty in data aggregation over the levels (PMI, 2017, p. 150).
Its’ also cumbersome in managing changes that mirror the actual status of the deliverables due to the time and effort associated with the process, which can be a major shortcoming since projects by nature have a high likelihood of encountering changes. This leads to a derailed WBS that doesn’t reflect the actual status of the project plan especially for changes that lie far in the future, creating room for scope creep, missed deadlines, incomplete deliverables or even budget overrun (PMI, 2017, p. 150). Lastly, it can easily be misinterpreted as a project plan.
PMBOK guide edition 6, discusses about creation of WBS in chapter 5.4 and underpins the importance of WBS as providing a framework of what is to be delivered and done once or predefined stages in the lifecycle of a project. It further states that the work packages groups activities where work is scheduled and estimated, monitored and controlled. But it also explicitly states that work in this context is not necessarily the work done but can also refer to the outcome (work products or deliverables) and not the activity itself. Agile introduces Feature Breakdown Structure (FBS) which enhances this difference.
FBS, instead of using activities in the control, planning and work packages, it uses features and stories. This distinction is important for the agile team, because they don’t have to worry about the work series to be performed but rather focus on shipping a functional deliverable, within the defined time and resources to meet the defined deliverable objectives. The structure is used in agile approach of planning projects and is centered on user stories
which belie the strength of agile by delivering values to the user at the high level of the hierarchy. This supports continuous delivery and integration, allowing customers to get quicker value, as the team remains focused on delivering shippable products rather than focusing on the work to be done. Unlike in the WBS, this abstraction of implementation from the deliverables is important even for products that lie further in the future, reducing the risk of being derailed from the project scope (Wettergren, 2020). Second, it supports just-in-time story development, eliminating requirements
specification and allows a team to still focus on deliverables while accommodating changes even later in the project.
This enables the team to have better evaluation of the impact of the decisions made at all levels of product development through accommodating improved and detailed definition of deliverables, hence maintaining the relationship between a product deliverable and its constituents (PMI, 2017).
It is useful for expectations and communication management, ensuring that it covers not more or less than defined in the project scope to meet stakeholders’ expectations. Similar to WBS, it helps the team members to have a clear understanding of their roles and when a deliverable is considered complete due to early definition of “done” for a deliverable. This boosts their confidence of project understanding, accountability, and transparency. (Dean Leffingwell, 2009). This also ensures that the development of the product has the right people involved and they are communicating together.
On the other hand, since it focuses on deliverables, there is a high risk of losing focus on how much details may be necessary to achieve the completion of a feature. It may be difficult to find a good estimation of deliverable decomposition to reach a “done” status. (Wettergren, 2020). Another shortcoming is that it fails to show dependencies between features.
So there it is, the discussion between advantages and disadvantages of WBS and FBS in the traditional project planning and agile project planning. What is your take?
Project Management 