What do I do when somebody asks for a Work Breakdown Structure (WBS) on an Agile project? Should I run for the hills or should I explain that a WBS is built in?
Run for the hills?
The case for running for the hills is that a WBS is a common feature of Traditional Project Planning. So if the requested deliverable is traditional then possibly the person requesting the deliverable has traditional expectations. In which case you might be better off going somewhere where Lean-Agile is well understand and appreciated.
But maybe you don’t have to run for the hills. Maybe you are already producing a WBS in your Lean-Agile project. You just call it something else.
Traditional WBS
A WBS is “A task-oriented detailed hierarchical breakdown, which defines the work packages and tasks at a very low level” (Agile Project Planning). A WBS is used to create a Gantt chart. Just put a start and end date against each of the tasks in the WBS and you’d have a conventional project schedule.
A traditional WBS reflects traditional beliefs in functional division of work leading to a Waterfall process and the assumption that all planning can and should be done up front. A WBS will typically be a phase for Analysis, and others for Design, Development, Testing, Release, etc. Many of these phases and sub-task produce interim deliverables and are the responsibility of a specialist role.
As an example here is a Work Breakdown Structure (WBS) I got from the Principle Based Project Management Information and Training Site.
Work Breakdown Structure (WBS)
To be honest I find much of the example WBS rather uninteresting. For me it focuses on the wrong things:
- functional role responsibilities, e.g. PM, Software Development
- job description / task management for roles, e.g. PMs must do Risk Management
- interim deliverables, e.g. Unit Test Cases
I find these uninteresting because I don’t think I have to plan for them. In general I can just assume that competent people will do the job I hire them to do.
But a WBS, like the closely related Gantt chart, suggests to those with a traditional project bent that the creator of the WBS knows what they are doing. Of course, that isn’t necessarily true, but there you go.
Agile WBS
WARNING: I’m not advocating creating a special Agile WBS – that would be a waste of time. I am just pointing out you are probably already producing something that is similar, for a similar reason. So if challenged by a traditionalist you have a more-or-less ready answer.
Lean-Agile has such a breakdown of work packages and tasks: the trusty Release Plan. However this approach turns the traditional WBS on its head in three ways:
- the focus on functionality delivered to production in a collaborative manner rather than interim deliverables aligned with functional role responsibilities
- leave doing the job to the professions on the team rather than imprinting the job description in every project plan
- the acceptance that planning should be refined over time, from high level to detailed, rather than trying to plan everything at project initiation
An XP style Release Plan maps Epics and User Stories out to give a list of features to be built over time. It is a high level WBS and project schedule in one, in the same way that a Gantt chart is a combination WBS and project schedule.
The Agile approach means you start with a high level WBS and end up with a detailed WBS. Additional detail is added when it is appropriate, for example, Scrum or XP teams will do a Sprint plan that features detailed tasks. This is all part of Agile Project Planning.
An Agile WBS is more likely to be fresh than a traditional WBS because it is refined over time. In an Agile team the plan, and hence WBS, is refined in a Iterative Incremental manner as more is learnt about the project/product. As new features become obvious they get added to the Release Plan. When it becomes obvious a feature isn’t needed, then that work is removed from the plan.
So if somebody asks whether you have WBS for your Agile project, you can safely say “Don’t worry. Got it covered”.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
Is there suppose to be a friction if you try to follow AGILE methodology while aligning to Work package deliverables which are part of SLA.
Friction arises if either party is more concerned with adherence to the SLA. or formal work package deliverables, than delivering a product that the client needs.
That has little to do with Agile although Agile, in my opinion, is more likely to lead to a product that is fit for purpose and might bring this friction to the surface.
Hi,
Can traditional project management tools such as work breakdown structure (WBS) be used in XP?
A WBS can be used in XP but, in my opinion, do not add much value.
WBS is deliverable oriented, not task oriented.
This is a huge confusion about this tool, and unfortunately, lot of people have it.
I believe a WBS is about work i.e. tasks. In contrast a Product Breakdown Structure (PBS) is about deliverables. An Agile Release Plan is both, tasks align completely with deliverables. So, in my book, a Release Plan can be both a WBS and a PBS. I admit, I am not a fan of either.
This is completely incorrect. A WBS, by definition, is a deliverable oriented document. A WBS, by definition, does not include activities and tasks. Activities can be created as a child of a work package, but they aren’t part of the WBS output.
I agree there is considerable confusion about a what is WBS. There seem to be two schools of thought. (1) Prince2 distinguishes the PBS because it is deliverable focussed, in contrast to the task based WBS. The example I shared above is about tasks / general responsibilities. (2) Other people, like Juan and Alexander, see no such distinction between a PBS and WBS. Similarly, the Work Break Down Structure site, uses the deliverable variant of the WBS.
Personally I think a PBS, and equivalent deliverable based WBS, has more value than a task based WBS.
But none of this changes my basic argument that an Agile Release Plan fulfils this function, amongst others. It also happens to be deliverable focussed.
Completely agree.
The WBS was originally invented by the NASA in 1968. It was part of a military spec for weapon systems (spec MIL-STD-881 Revision C – 2011): http://everyspec.com/MIL-STD/MIL-STD-0800-0899/MIL-STD-881C_32553/
This standard practice has been revised and refined years after years by the Project Management Institute, which publishes the guide: https://www.pmi.org/pmbok-guide-standards/framework/practice-standard-work-breakdown-structures-2nd-edition.
A WBS is the hierarchical decomposition of deliverables (work packages) that your project scope encompasses. It’s the WHAT of your project, while the Gantt chart or Scrum board are the HOW and WHEN.
That’s why you never use verbs when you name a WBS component, because a verb would imply how you will do it. Truth is, you don’t know how yet.
It is not very detailed, as most WBS don’t have more than 100 WBS Component. It is recommended not to stop the breakdown when you can complete the work within a Work Package (the leaves of the WBS) within ~80 man hours.
I meant recommended to STOP the breakdown when Work Packages are around ~80 man hours, sorry.