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.

Un WBS bazat pe Agile este organizat în jurul unor unități de funcționalitate ale utilizatorului
final - denumite în mod obișnuit povestiri ale utilizatorilor. Fiecare poveste a utilizatorului
reprezintă lucrarea de a furniza această creștere a funcționalității. În WBS bazate pe Agile,
Caracteristicile sunt descompuse în Epics (povestiri mari de utilizatori) și Epic în povestirile
utilizatorilor. Poveștile utilizatorilor sunt descompuse pentru a reprezenta funcționalitatea care
poate fi terminată într-o singură iterație - de obicei una până la patru săptămâni, în funcție de
echipă / proiect. Fiecare element WBS la nivel de frunză reprezintă software-ul de lucru care
trebuie produs prin analiza, proiectarea, codarea și testarea cerinței în povestea utilizatorului.
Deoarece fiecare poveste a utilizatorilor este atomică, povestirile pot fi re-prioritizate, adăugate
sau eliminate, fără a schimba domeniul de aplicare, cu condiția ca mărimea / efortul total al
articolelor din sfera proiectului să nu se modifice. În plus, dezvoltarea iterativă facilitează lansări
multiple (implementări) în cadrul unui proiect. Deci, povestile utilizatorilor sunt în mod obișnuit
programate în cadrul unei iterații și a unei lansări. Rețineți că, până când o iterație a început,
povestirile din cadrul acestei iterații pot fi modificate, ca parte a planificării iterației. Este posibil
să existe un WBS hibrid, unde unele subproiecte sau livrabile sunt produse iterativ, iar altele
sunt produse utilizând un ciclu de viață diferit. De exemplu, o nouă implementare a sistemului în
care software-ul este produs în mod iterativ, iar infrastructura (de exemplu, rețeaua, serverele,
spațiul de stocare) este produsă într-o manieră cu mai multă cascadă. ... TBD creează o serie
de grafică cu tradiția WBS și Agile WBS, cu caracteristici descompuse în epice și povestiri.
Proiectele agile au un WBS. Cu toate acestea, diferențele de perspectivă și de terminologie
pot provoca confuzii între managerii de proiect familiarizați cu WBS pentru un SBS bazat pe
dezvoltarea sistemului (SDLC) bazat pe WBS și Agiliști, care poate să nu fie familiarizați cu
rolul jucat de WBS în proiecte. Să aruncăm o privire asupra scopului unui WBS și asupra
diferențelor dintre proiectele bazate pe SDLC și cele iterative.

Un WBS este scheletul (structura) unui proiect. Organizează toate livrările necesare pentru
finalizarea proiectului. WBS este utilizat pentru estimarea, planificarea și monitorizarea stării
proiectului. Din PMBOX, WBS este o "descompunere ierarhică orientată spre livrare a
lucrărilor care urmează a fi executate de către echipa de proiect pentru a realiza obiectivele
proiectului și a crea rezultatele dorite". Rețineți că structura WBS este determinată de
rezultatele pe care proiectul le va produce.

Un WBS bazat pe SDLC este în mod normal organizat în jurul principalelor livrări (de
exemplu, documentul de definire a cerințelor, documentul cu specificațiile de proiectare)
care urmează să fie produs ca parte a ciclului de viață. Elementele WBS sunt estimate la
caracteristicile de nivel înalt cunoscute (la momentul planificării) care urmează să fie
finalizate. Cu toate acestea, într-un WBS bazat pe SDLC, aceste caracteristici nu sunt numite
ca livrări separate. De exemplu, într-un WBS bazat pe SDLC, definirea cerințelor,
specificațiile de proiectare, software-ul codificat și cazul de testare ar putea fi numite ca
elemente separate WBS.