1

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.

  • 1
    Decomposing user stories is analogous, but perhaps a bit less formal. – Todd A. Jacobs Jun 14 '18 at 3:11
1

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.
  • Let's say that mixing both approaches, I will still use the WBS with my agile approach. Do you think that it will be ok if my WBS has a leg like 2.Execution >> 2.1. Sprint #1 >> 2.1.1. Feature/Story #1 >> 2.1.1.1. Design >> 2.1.1.2. Code >> 2.1.1.3. Test..? An in within Design > 2.1.1.2.1. Use case & 2.1.1.2.2. Prototype? – Maximus Decimus Jun 14 '18 at 18:38
  • Short answer: yes, it's OK. But the structure can overcomplicate job for your team and yourself. Here is why. Features are usually aimed to be no more than 1 sprint of work. If they are bigger, you should split them on two features (but still features!). So, if feature is just 1 sprint long, then IMHO your last level of hierarchy is waste -- because it will contain extremely small chunks. And one before it maybe too -- because they will segregate your team by specialization, but it's a different story. – Anton Nepomnyaschih Jun 15 '18 at 2:46
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.

0

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.

0

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.