Forget the WBS — in Agile, You Need a VBS
While the work is important, the value is even more important
A few years back, sitting at the conference room table with a half-dozen other project managers, we listened to a senior manager visiting from the corporate office, most definitely the HiPPO¹.
He was there to tell us how to improve our projects.
“The problem is you are doing it all wrong!”
He stood up, grabbed a marker, and started drawing boxes on the whiteboard. Then connecting them with lines in a hierarchy, while speaking over his shoulder:
“You need better work breakdown structures!”
We looked at each other. Most of us had managed projects for years and created many work breakdown structures (WBS). Many were traditional project managers, and some were moving into agile.
But work is work and all projects have lots of work, right?
The Project Management Institute defines a WBS as a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables²
The key is the total scope of work. In a traditional project, a WBS is often organized by phases, for example:
Not rocket science, right? So how could we be doing it all wrong?
Thinking back, I now understand what he was getting at.
For a traditional project, the total scope of work is defined up-front, and carefully controlled during project execution.
If the scope needs to change, then a formal change request process must be followed.
What he was really telling us was that we were not fully planning all the work up front, because if we did, we would have proper Work Breakdown Structures.
Therefore we were doing it wrong.
Do we need a WBS in agile?
Agile ways of working requires a different mindset, which, for a traditional project manager like me, is not always easy (you can read more about the agile mindset in my post here).
Mike Griffiths, in his article “The Agile Alternative to Communications Management Plans”,³ wrote :
A product backlog is somewhat analogous to a work breakdown structure.
The key is “somewhat ”. While the full scope of work, over time, derives from the product backlog, in agile we simply don’t know all the work up front.
And that’s on purpose. Instead, we focus on delivering value.
In agile, we think in terms of products. We create an initial product backlog, with a high level vision, and then start refining and adding incrementally, setting priorities, and delivering working, valuable software every iteration.
In agile, break down the value, not the work
Think of this as a value breakdown structure, or VBS. I’ve found that most agile tools support building a VBS, even if they don’t specifically call it such. For example, in Atlassian’s Jira:
The idea is to break work down into shippable pieces, so that large projects can actually get done and you can continue to ship value to your customers on a regular basis.⁴
Similar to a WBS, a VBS is hierarchical, for example:
- Initiative — (sometimes called a Roadmap) a collection of Epics that drive toward a common goal. Initiatives are usually worked on by multiple teams over multiple iterations
- Epic — (sometimes called a Feature) a large body of work that can be broken down into a number of smaller items (called Stories or Tasks). Epics usually span multiple iterations
- Story or Task — Stories (often called User Stories) capture functional requirements that are valuable from a user perspective, while Tasks capture anything that can be of value to the team working on them. Stories and Tasks are sized to complete in a single iteration
A VBS may look like this:
Of course, this is not the only way of structuring a VBS — the key is the focus is not on the work — it is on how the end user perceives the value of what is delivered.
A VBS example from Banking
Initiative — Mobile Banking
As a Banking customer, I want to securely bank via an App on my mobile phone, so that I am not tied to my desktop, or don’t have to visit a branch.
Epic — Send Money
As a Mobile Banking customer, I want to securely send money from my account to another person’s account using my mobile phone, so that I don’t have to give them cash, or access Internet Banking, or stand in line at a Branch to make a transfer.
Story — Send Money via Phone Number
As a Mobile Banking customer, I want to use my phone to securely send money from my account to another person’s account, using their mobile phone number, so that I don’t have to enter their account number or other details.
Another Story — Send Money via Email Address
As a Mobile Banking customer, I want to use my phone to securely send money from my account to another person’s account using their email address, so that I don’t have to enter their account number, phone number or other details.
Task — Improve App security
Implement the latest version of the security framework in the Mobile Banking App to improve security.
Imagine the team has implemented the story “Send Money Via Phone Number”.
The next priority in backlog was originally “Send Money Via Email Address”. From a technical perspective, this makes sense because this story is an extension of “Send Money Via Phone Number”.
Imagine we find that customers love the new feature to transfer by phone number, it’s been a big hit.
However, they are not that interested to transfer by email address. Instead they are asking to pre-populate a text message after the transfer.
This way they can easily send a text message to the recipient to watch for the transfer, without having to type in all the details.
And maybe add an emoji 😃
So a new story, “Send Text Message After Transfer” is written and prioritized for the next iteration. This will deliver more value to the customer.
Meanwhile, the story “Send Money by Email Address”, stays in the backlog, at least for now.
Endnote
Moving from traditional project management to agile ways of working, I’ve found it best to think differently about how to view the work, and how to break it down so that it can be prioritized and allocated to teams.
A traditional work breakdown structure, or WBS, doesn’t work very well, and may not even be possible — instead, I’ve learned to concentrate on delivering value, one iteration at a time.
Otherwise we may find we really are doing it all wrong.
[1] HiPPO — Highest Paid Person in the Office (or meeting) https://www.inc.com/scott-mautz/the-highest-paid-person-in-meeting-is-most-dangerous-voice-according-to-whartons-adam-grant.html
[2] A Guide to the Project Management Body of Knowledge, Sixth Edition (2017) Project Management Institute, Inc., Newtown Square, PA. pp156–159
[3] Mike Griffiths The Agile Alternative to Communications Management Plans Projectmanagement.com (09 Sep 2020) Project Management Institute, Inc., Newtown Square, PA.
[4] Max Rehkopf Agile epics: definition, examples, and templates https://www.atlassian.com/agile/project-management/epics
