Convert your work breakdown structure into an user story map

I share this post!

Convert your work breakdown structure into an user story map is the key to do good PMP and agile project management at the same time.

Firstly, there are three things to keep in mind:

  • Yes, it is possible to convert a workbreakdown structure into an user story map
  • It is an iterative process
  • No, there is no need to convert your workbreakdown structure into an user story map as both can be used for communication purposes with different audiences

There is no unique way to do this transition, but this is how I do it:

1. Start by creating a product oriented work breakdown structure:

Regardless in which phase of the project we are, whether we joined the project at the beginnig or we take the project over from another project manager. We need a work breakdown structure. If there is no one, talk with the team and other stakeholders to create one as soon as possible.

How to create a product oriented work breakdown structure?

  • Together with the business analyst (if any), I meet the key business stakeholders to understand what they want, except it there is a clear scope statement document
  • The buiness analyst and I decompose the needs in potential sub products. The first version of your work breakdown structure is born
  • We present the draft to SME’s, architects and the team to finetune the workbreakdown. As it is an iterative process, it is OK if at the beginning we only have 2 levels of high level subproducts
  • We use backlog refinement meeting to continue updating the work breakdown structure if needed

In the article “How to create a product oriented work breakdown structure” I share with you how I created a product oriented wbs for a recommendation system.

Don’t worry about having the perfect work breakdown structure since the beginning. It is only when we are starting the last sprint that we have the impression that we have the final-final version of our work breakdown structure. However, changes that impact our product may occur, therefore our work breakdown structure will be also impacted.

Should I add delivery phases or project life cycle phases on my work breakdown structure?

Personally, I don’t do that. There is nothing good or bad about adding phases on the work breakdown structure, but I prefere to communicate phases in my planning, not in my work breakdown structure.

However, I do include in my work breakdown structure the pieces of the product that will be added in each of the phases.

Which tool to use to create a work breakdown structure?

MS Project, Excel, Power Point, Enterprise Architect, Visio, doesn’t matter, up to you. For the moment, for me is enough to use Power Point SmartArt for building the work breakdown structure chart. From experience, it is easy to use and change when I am working with different stakeholders.

However, I do not use Power Point for the work breakdown dictionary.

2. Creating an user story map from the work breakdown structure

Start this process bottom up.

I always keep this in mind:

  • The goal of the user story map is help you to manage the project, no just a conceptual exercise
  • Master the tool used by the company as much as you can (Jira, Target Process, etc)
  • Don’t replace nor transform the work breakdown structure by the user story map, but create the user story map starting from the work breakdown structure

The process I follow looks like this:

  • I identify the “entity” in the tool that developers use to monitor their development tasks. From my experience, whether user stories or tasks inside the user stories
  • I consider the workpackages of the work breakdown structure to be “features” and the level above to be “epics”
  • With the team or some of them, iterate starting from the user stories or task until we are confortable with the grouping of them into features and epics
  • Final check, compare the work breakdown structure with the final version of the user story map to be sure that you can make the link between workpackages, epics and features

Iterating to create the user story map is key

Some things can happen after this:

  • A workpackage that was a feature at the begining becomes an epic
  • A workpackage that was a feature at the begining becomes two or more features
  • Rare, but might happen, a workpackage that was a feature becomes an user story

I try to avoid this error:

As the work breakdown structure and the user story map are communication tools with different levels of granularity for different audiences, the goal is not to replace one by the other.

After the iteration, I avoid as much as I can to impact the work breakdown structure by creating additional workpackage to match the number of epics and/or features.

As conclusion:

To use your work breakdown structure as starting point to create your user story map keep this in mind:

  • A top down approach for the work breakdown structure
  • A botton up for the user story map
  • Iterate with the team until you all feel confortable
  • Check and map

I hope this helps.

And you, how do you transform your work breakdown structure into a user story map?

Cheers,

Falcon