Compare and contrast the development of a WBS in traditional project management versus development in an agile environment. Solution 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. In case of traditional project management WBS is organized around the primary products of the project (or planned outcomes) instead of the work needed to produce the products (planned actions). Since the planned outcomes are the desired ends of the project, they form a relatively stable set of categories in which the costs of the planned actions needed to achieve them can be collected. A well-designed WBS makes it easy to assign each project activity to one and only one terminal element of the WBS. In addition to its function in cost accounting, the WBS also helps map requirements from one level of system specification to another, for example a requirements cross reference matrix mapping functional requirements to high level or low level design documents..

1. Compare and contrast the development of a WBS in traditional project management versus
development in an agile environment.
Solution
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.
In case of traditional project management WBS is organized around the primary products of the
project (or planned outcomes) instead of the work needed to produce the products (planned
actions). Since the planned outcomes are the desired ends of the project, they form a relatively
stable set of categories in which the costs of the planned actions needed to achieve them can be
collected.
A well-designed WBS makes it easy to assign each project activity to one and only one terminal
element of the WBS. In addition to its function in cost accounting, the WBS also helps map
requirements from one level of system specification to another, for example a requirements cross
reference matrix mapping functional requirements to high level or low level design documents.