Bundle the WBS up with the idea of a backlog and sprints and you have a great way of managing multiple streams of work as well.
But about 70% Project Management textbooks that I look at are describing a WBS framework incorrectly. No wonder people think so many PM's are pointy haired Dilbert Bosses.
Let me get specific for you;
A WBS is doing it wrong if;
- It focuses on stage gates for a project
- A WBS that has a top level set of domains like PLAN, ANALYSE, DESIGN, BUILD, TEST, RELEASE is so so wrong, and this has nothing to do with the agile way of working. It is just plain wrong.
- It focuses on time boxes as the top level - or any level really - containers.
- The WBS mainly focuses on the work - the thing to be built. Not the time it takes to build it. That's an effect on sizing the work and comes after figuring out the goals of the customer.
|From a 2006 blog post. Agile people don't do this any more though.|
A WBS is doing it right if
- A WBS focuses on customer goals
- The top level is the overall goal of the customer
- The next levels are goals and capabilities that trace into that goal
- A WBS describes tangible things of value to the customer
- Customers do not care about your activities (or if they do, it's not a part of planning your work.)
- Customers care about the outcomes and capabilities you will be delivering to them.
- WBS elements should all be worth the money people spend on them, and thus should stand alone or have clear relationships to how the enable other things of value.
Comments? Corrections? Let me know.