Search This Blog

Loading...

28 August 2009

Using the WBS in Scrum

The DoD handbook points us to defining three levels of a WBS when managing a project, and the same is probably a requirement for a supplier in that environments; show me the top three levels of your work breakdown so I have confidence you know what you are deliverring (and how you'll get there.)

My training - both in practice and education has always made me think very hard before going down to work activity level in a WBS.  The WBS tool is supposed to be about deliverables and like Mr Covey advises, we need to keep the end in mind.  So WBS items should always be focused on physical deliverables.

In practice in my non-militry career there have often been compromises to this principle and I am comfortable with this, becasue more important that WBS principles is the need to break up work into managageble and undertandable chunks.  Work with your team, sponsor and partners on the WBS and make the compromises where you need to.

But the principle of the top three levels being defined is very useful and not one to ignore.

I have the top 3 levels of my WBS defined right now and I am rnning a scrum project as close to vanilla as I can manage.

What are they?  The details are private, but it looks a little like this;

1. Business system solution
1.1 Software application A
1.1.1 Business Product X supported
1.1.2 Business Product Y supported
1.1.3 Business Product Z supported

1.2 Software application B
1.3 Software application C
What does this mean?

The business system solution is the business domain we are - for want of a better term - re-engineering.  It roughly equates to the way a department does business via a set of products.  Application A is one of a handful of software applications we are building.  It's a system of systems kind of thing.  Business Product X is shorthand for the mandatory (in Kano speak) requirements.

Where does the product backlog live?  At the application level - Level 2.  Then it's contents are grouped (guided via the minimum mandatory feature set) into releases that align with releaseable clusters of system capability.

Level 3 acts as a guide to what is important and does change over time.  But it is still serves as a tangible feature set per WBS item.  There is more detail below each of these, but it's details embedded within the product backlog - and that is suficient for the most part.

The systems are supported by independent teams and the product backlogs are orderred and grouped into pragmatic clusters of releaseable chunks.  But it remains dynamic once you get past the first release of a product (X,Y, Z) then you can pretty much prioritise whatever you want as the next releaseable feature.

This system misses something, and it's accomodated by a solution that feels wrong to me; a level 2 Change Management WBS item which kind of mirrors the product development WBS items.

What I think I would prefer here is that the training, documentation and communication activities were packed up in the product backlog and treated like any other feature and sat within that level 3 WBS item.

I am not running at aspect of this project and so what I like is beside the point.  Maybe next time.

Questions? Comments?
Picture by Leo Reynolds CC at Flickr