In an earlier blog post, we compared the WBS Dictionary to the Agile Definition of Done. However, we never reviewed any connection between conventional project management Work Breakdown Structure (WBS) and the decomposition of the product backlog to produce the sprint backlog.  Before we can describe what completion of the item looks like, we must first identify those things that we will need to produce either in this portion of our conventional projects or in our sprint.

In conventional projects, we start with the scope and identify all of the things we will need to do to be able to produce the scope objectives.  Often this decomposition is performed on the entirety of the scope, though this is not a requirement. That is, at the beginning of the project we are decomposing all we know about the project often through to the end of the project. We identify the list of all the work to produce the scope.  The breakdown will often be associated with parts of the organization and each will have an allocated budget for the project based on the results of the WBS and estimates that are generated.  To evoke the work items and build the WBS we will:

• identify the deliverables per iteration
• decompose the deliverables to specific components
  • brainstorming / collaboration
  • interviews
  • historical record
  • process documentation
  • subject matter experts
  • external influences (legal and regulatory)
  • logical ad technical dependencies

For our agile work, we make no attempt to be able to predict work that is too far out.  However, we will still need to decompose the highest priority product backlog items (whatever we can fit into our sprint duration).  So the only real difference between these two is the time horizon and perhaps the level of formality via documentation.  If that is true, then we can use many of the same techniques or disaggregating the work.

The difference between agile and conventional project management is not as large as many people would have you believe.  The time horizon for conventional projects is not a hard rule of project management. In fact, the PMI phrase is progressive elaboration which accounts for this uncertainty.  The estimating techniques you would employ for conventional projects can easily be used for the other and vice versa.  We not be shackled to either conventional nor agile approaches but map our approach to the situation, and employing whatever approach, no matter the origin to the situation in ways the reduce risk and improve the probability of success.