WBS and agile approach

Question

I have been reading 3 books about Agile Project Management and in all of them there is no concept about WBS even in the book of the agile practice from agile alliance that comes with the PMBOK 6th edition.

In fact, in one of those books, the WBS is only displayed in a picture to compare the waterfall project management vs agile project management. Even the EV management is slightly different with other formulas that differ from PMI methodology.

However, there are some PMI techniques still used in agile approach, but it is not structured like in the processes groups

My question is, when you are initiating a project in an agile approach the WBS it is OUTDATED, OBSOLETE, DEPRECATED, USELESS?

I tought that I could represent my features in sprints with deliverables in my WBS, but I am confused now.

Answer 1

No, the WBS is not outdated, obsolete, deprecated, nor useless.

The WBS is just a decomposition of WHAT you want to deliver.

Building a WBS is not a one-shot task, but it is an interactive and iterative process.

One best practice in project management is to create a product oriented WBS, that you will use later to structure your planning.

In my article "how to create a product oriented WBS", I go through this process with an example for a recommendation system.

In agile we talk about user story map, which is a view of the user stories organized by EPICs and Features.

Is the user story map the same that the WBS?

No, these tools are not the same, but they can be used together as from my point of view they are complementary.

From my experience, the WBS is better to communicate with stakeholders outside the team, and the user story map with the team.

If you want to know how you can transform your WBS into a user story map, you probably would like to give a look to my article "From a WBS to a user story map".

I hope this helps.

Cheers Falcon

Answer 2

I agree that the by strict definition of a WBS and its use lends itself to best be used in the waterfall methodologies...however like mentioned above some of its principles can be applied to managing the Scrum or Agile backlog concept. In Agile . you are essentially breaking the work down into Epics, Features, user stories...which closely matches Project, Deliverable, Work package on the WBS. I personally like the concept of building out a WBS for a Phase of agile work to create the back log. I like meeting in the room and using the post notes to get a high level vision of the work coming.

Answer 3

You can split your customer business goals -> on Epics, Epics -> on User Stories or Features. And think about it as about WBS. But there are significantly important things to take into account:

1. You can create backlog of Epics and Features early in the project, but better to use Rolling Wave approach, when you create detailed decomposition for first 2-4 weeks of work, semi-detailed for next 2-4 weeks and only high-level (Epics list) for the rest of the project. And then detail work when you come closer to the next chunk of Backlog.
2. Epics are not deliverables -- they can grow throughout your project (with needed simplifications of other Epics if you are in Fixed Price contract). Epics are more intention to improve some functionality or achieve some goals, not specific part of work to be completed.
3. Features are not tasks -- i.e. you should split functionality in business terms, not technical terms. Main criteria and benefit of this -- your customer should be able to prioritize features independently.

Answer 4

Depending on how you construct your WBS, that might be possible, but traditionally WBS's break down into tasks. This assumes I know all (or at least most) of the work that needs to be done up-front. This approach is impossible when solving complex problems where I need to do some work to discover what other work needs to be done. Therefor, since Scrum was particularly designed for this type of work (most product development is actually this type of work), Scrum uses an emergent backlog.

When I was learning Scrum, I looked at the backlog as a sort of WBS. There are a few reasons why this comparison is inaccurate, but for me, it worked as a transitioning approach. Only, instead of breaking down the work to be done, I broke down what I wanted the product to do.

Answer 5

I agree with what [I think ...] Mike Rowe is saying: the two concepts can be used together, and they very often are.

For instance, when we say that *"you are essentially breaking the work down into Epics, (etc.) ..." well, there's that same phrase again, just in different context. We've still got work, and we're still breaking it down. (But the scope-and-boundaries, and goals, of our breakdown efforts are now different ... and perhaps, "multiple and parallel.")

In the context of these projects, I still find value in applying WBS concepts at two distinct levels:

1. At the initial stages of the project, as we are trying to develop, or at least to predict or prognosticate, an over-arching expectation for it. But we then allow the team's self-directed activities to discover the details while the project is periodically held up against this initial breakdown (and, the breakdown is revised).

2. On a micro scale, awareness of WBS principles can prove to be more effective in ordering the team's short-term next activities, than "simple consensus" might be.

WBS concepts are also extremely valuable in determining what the initial project breakdown ought to be, in a large effort that might involve multiple [scrum/agile/what-have-you] teams. In my opinion, it's extremely important that each team be set with well-thought-out scope and boundaries, and that anticipated interactions between the various "team boxes" are as well-understood as they reasonably can be at this point. (And that we then revisit it from time to time, and publish new revisions.)

"Traditional [waterfall] WBS" broke down, so to speak, because we can't predict the entire future before we begin. Iterative methodologies (scrum, agile, and so on) were developed as a response to this, realizing that "well, we don't have to." But I'd argue that they certainly didn't discard any of WBS's good ideas. They just started applying them at different times, at different levels, and with both short-term and long-term objectives. By doing this, we think that we've improved the bathwater, but we didn't throw out the baby in the process.