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.