Forget the WBS —
in Agile, You Need a
VBS
While the work is important, the value
is even more important
Andrew Coates
·
Follow
6 min read
Sep 26, 2020
73
Photo by Jakayla Toney on Unsplash
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:
A Work Breakdown Structure
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:
1. 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
2. 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
3. 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:
A Value Breakdown Structure
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.
