Value breakdown structure in Agile

A few years ago, while 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 (Highest Paid Person in the Office/Meeting).

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 have managed projects for years and created numerous 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.

Agile ways of working require 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

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 but on how the end user perceives the value of what is delivered.

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 be done and you can continue to ship value to your customers on a regular basis.

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 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.

Now, imagine the team has implemented the story “Send Money Via Phone Number”.

The next priority in the 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 out 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 ask 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.