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