Where is the Work Breakdown Structure (WBS) in Agile?
Agile projects do have a WBS. However, differences in perspective and terminology can cause confusion between project managers familiar with a WBS for a System Development Life Cycle (SDLC) based WBS and Agilists who may not be familiar with the role a WBS plays in projects. Let's take a look at the purpose of a WBS and the differences between SDLC based and iterative projects.
A WBS is the skeleton (structure) of a project. It organizes all of the deliverables necessary to complete the project. The WBS is used for estimation, scheduling and monitoring project status. From the PMBOX, the WBS is "a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables". Note that the structure of the WBS is driven by the deliverables that the project will produce.
An SDLC based WBS is normally organized around the major deliverables ( e.g., requirements definition document, design specification document) to be produced as part of the life cycle. WBS elements are estimated on the known (at planning time) high level features to be completed. Howver, in a SDLC based WBS these features are not called out as separate deliverables. For example in an SDLC based WBS, requirements definition, design specification, coded software and test case could be called at as separate WBS elements.
An Agile based WBS is organized around units of end user functionality - commonly referred to as user stories. Each user story represents the work to deliver that increment of functionality. In Agile based WBS, Features are decomposed into Epics (large user stories) and Epics into User Stories. User stories are decomposed to represent functionality that can be completed within one iteration - typically one to four weeks depending on the team/project. Each leaf level WBS element represent the working software to be produced through analysis, design, coding and testing of the requirement in the user story.
Because each user story is atomic, stories can be re-prioritized, added and or removed without changing the scope, provided that the total size/effort of stories within the scope of the project does not change. Additionally, iterative development facilitates multiple releases (deployments) within a project. So, user stories are typically scheduled within an iteration and a release. Note, that until an iteration has started, the stories within that iteration can be changed, as part of iteration planning.
It is possible to have a hybrid WBS, where some sub-projects or deliverables are produced iteratively and other are produced using a different lifecycle. For example, a new system deployment where software is produced iteratively, and the infrastructure (e.g., network, servers, storage) is produced in a more waterfall fashion.
...TBD create a couple of graphics with tradition WBS and Agile WBS, with features decomposed into Epics and Stories.
Comments (4)
Brian Bozzuto said
at 7:38 am on Jun 2, 2009
Hi Sellers,
I'm afraid I must take issue with some of your description of the "traditional" WBS. In fairness though, I did have the same understanding you did until I recently met Robert Fried at a Rhode Island PMI chapter meeting. Mr. Fried is an outspoken expert on Work Breakdown Structures and is a co-author of the authoritative book on the topic (book available here: http://www.amazon.com/Work-Breakdown-Structures-Foundation-Management/dp/0470177128/ref=sr_1_3?ie=UTF8&s=books&qid=1243942188&sr=8-3).
During his presentation he posed the question of what is ultimately encompassed in a WBS and I naively said that it included individual tasks. Robert indicated this is a common misconception, but that the PMI has been very clear for some time that a WBS is focused on deliverables, NOT tasks or schedule. To quote him...
"A WBS, as defined in the PMBOK® Guide—Third Edition is ―a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The WBS is decomposed into work packages. The deliverable orientation of the hierarchy includes both internal and external deliverables.
With this definition, it is clear the WBS provides an unambiguous statement of the objectives and deliverables of the work to be performed. It represents an explicit description of the project’s scope, deliverables and outcomes—the "what" of the project. The WBS is not a description of the processes followed to perform the project… nor does it address the schedule that defines how or when the deliverables will be produced, but rather is specifically limited to describing and detailing the project’s outcomes or scope."
(http://ca.com/files/WhitePapers/fried_wbs__pmi_global_congress_202925.pdf)
Brian Bozzuto said
at 7:38 am on Jun 2, 2009
When talking with him later, he quickly agreed that in large projects, one need not decompose an entire WBS at once, and that the structure is quite conducive to incremental definition and elaboration. Based on that interpretation, it seems the primary difference would be the context of the description of the items within a WBS. Whereas a traditional project may discuss deliverables, Agile projects frequently apply user stories, which would be more focused on "outcomes". However, neither the WBS definition, nor Agile projects seem to mandate one or the other. I would argue that, for all intents and purposes, a WBS could be used as a product backlog. In fact, most good product backlogs leverage the types of descriptive hierarchies that Mr. Fried advocates for. If you read through the white paper I linked to, he will even show several good "visual" representations of a WBS to more clearly communicate the scope of a project to executives or other stakeholders.
sellers.smith@gmail.com said
at 10:02 pm on Jun 2, 2009
Brian, thanks for the feedback. I have edited the definition to pull out references to activities. IMO the key issue here is that typical SDLC WBSs organizes deliverables around phases/activities (analysis, design, coding). Whereas Agile methodologies organize work around features/functionality (aka User Stories).
Bruce Benton said
at 7:40 pm on Jul 27, 2011
This is a bit of an old thread but it is something that I am investigating now so I thought I would add a couple of comments.
Classical WBS documents do not have to be organized functionally. I have long advocated a feature, or object, based structure to a WBS since it optimizes the maintainability of the structure. Put simply, which is likelier to happen? A new feature is added to or an existing feature is deleted from your project or a fundementally new activity will be discovered in your project? In general, far more change in projects is associated with scope change than a changing activities (i.e. whatever our process is we follow it for most features). This means that structuring around the features will simplify your maintanance when it is inevitably required. It also means that several of those activities you mentioned above will just show up under each feature so it is really just a transformation of the same information into a more maintainable structure.
The more signifant difference to me is the expectation at the beginning of a classic project that the WBS should be "complete" and that in an agile project there is less of a static sense to this list since it will evolve over the course of an agile implementation as customer needs are refined and time and resource constraints kick in.
You don't have permission to comment on this page.