• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Agile WBS

This version was saved 14 years, 10 months ago View current version     Page history
Saved by sellers.smith@gmail.com
on June 1, 2009 at 2:28:40 pm
 

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 traditional System Development Life Cycle (SDLC) 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 and activities necessary to complete the project.  The WBS is used for estimation, scheduling and monitoring project status. 

 

An SDLC based WBS is organized around phases of the project - analysis, design, coding and unit test, integration testing, and deployment.  Also, major deliverables (requirements, design specification) are usally completed at the end phases.  WBS elements are estimated on the known (at planning time) high level features to be completed.  Good project managers will add a reserve to deal with the uncertainty of these estimates and control the addition of new features (aka Scope Creep),  because these are areas where a project can easily run over budget.

 

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.  The activities to complete each user story consist of the work necessary to define the requirements, design the solution, and code and test the solution. User stories are decomposed to represent functionality that can be completed within one iteration - typically one to four weeks depending on the team/project.  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.

 

While it is not necessary that user stories be organized hierarchically, user stories can be grouped into higher level collections (e.g., features, themes, goals) and large stories (typically called Epics) can be decomposed into smaller stories.  This can lead to a situation where the functionality to complete a high level feature (or Epic) can span multiple iterations and even releases.  

 

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 (0)

You don't have permission to comment on this page.