The Yin Yang of Projects: Using WBS in hybrid project management.

Postado por admin em 11/Apr/2019 - Sem Comentários

In this chapter of the hybrid project management series, I will talk about the Work Breakdown Structure (WBS) Technique from the PMBoK and how it can aid a Product Owner(PO) in creating better manageable user stories for the project. If miss the previous article of this series(Roles in hybrid management), just click here.

In the Chinese tradition, there are a number of tu or diagrams that attempt to give the Dao, the metaphysical principle believed to control the operations of the universe, a visual representation among them, the most famous is the Taijitu or the Taiji Diagram. There are a few variations, but according to the accepted tradition, the standard Taiji Diagram should be a circular diagram that inscribes a Yin Fish and Yang Fish embracing each other within and eight trigrams or sixty-four brokendown hexagrams outside the circle. This was the first Breakdown Structure in human history.

No alt text provided for this image

Since Yin and Yang means two principles, one negative, dark, and feminine (yin) , and one positive, bright, and masculine (yang) , the Chinese needed to break this concept into smaller chunks to better understand the universe. By the transformations of the Yang and the union of the Yin the 5 elements arose and from the elements the seasons of the year. Breaking it even further, each season of the year contains the 10,000 things that represents the existence.

In the world of traditional project management, the technique used to break key concepts (or requirements) is called Work Breakdown Structure (WBS). this process occurs shortly after the project scope is defined, and the role of the Project Manager is to break the project requirements into smaller components to better manage them, called work packages. The main benefit of this technique is that it provides a structured view of what should be delivered. By analogy a working package in the SCRUM Framework is called a User Story.

Anyone who works with SCRUM eventually has used this technique without realising that it was part of a PMBoK process. It is common in a SPRINT planning session that the PO presents the created user stories to the team, but after detailed analyzes made by all stakeholders, they may realize that this story is too big or too complex to be solved in a SPRINT. When this scenario happens, this user story becomes an EPIC. An Epic must be then split into smaller user stories so it can fit inside a SPRINT. Sounds any bells? Also in some companies or squads, there is a concept of grouping some related epics, that will be called THEME. So we can say that a number of related User Stories can form an EPIC and that some EPICs can be grouped to form a THEME, or in other words, we can create a WBS.

No alt text provided for this image

The argument of those who follow pure SCRUM is that at the beginning of the project, all work/tasks are not known, so WBS is useless for SCRUM projects. This is a bad misconception because they miss out the huge benefits which WBS offers in Agile environments, the ability to plan, track and manage complex projects using a visual structure that show the big picture of a project and helps break them down into smaller chuncs which can compose a Sprint.

A wise man makes his own decisions, but an ignorant man mindlessly follows the crowd. -Chinese Proverb

Another benefit that can be missed is that WBS is a great Tracking tool that can also aid with the predictability of the deliveries of a project. I can also mention that a WBS will help the PO better prioritize the User Stories, since the WBS graphic give a better view of the big picture of a project. Next, I will show you how I create the WBS in my hybrid projects.

Here is how to mount your WBS in a hybrid project.

First of all, you should choose a tool to help create your WBS. There are many available tools online that you can download and use on your computer, just Google WBS TOOLS, and you will find a good one for you. Either way you can always count on post-its or pen and paper that will also get the job done. Particularly I prefer to use the Xmind tool, which is free and user frendly, in creating my WBS. You can download it from this website here.

After choosing your tool we can start to build our WBS. There are many ways for you to represent your structure, but the most common are:

  • Using phases of the project life cycle as the second level of decomposition, with product and project deliverables inserted in the third level.
No alt text provided for this image
  • Using major deliverables as the second level of decomposition.
No alt text provided for this image

My preference is for the second option, and it is the option that I always plan in my projects, because dividing a project by components, allows me to deliver value to the client faster and earlier. Let me explain better, if we look closely at the first option, in order to start delivering the kitchen items I would have to go through the design and purchase steps to start the installation phase. When I plan to split my project into components (second example), I start to add value to the client with the first set (Appliances).

Let me give you a practical example of why the second option gives an advantage. Let’s assume that in the middle of the project, the client does not have more money or time to sponsor the project until you can complete it (sounds familiar?), And therefore we can only make 6 deliveries. in the first example we would have the design and purchases of the appliances, fixtures and cabinets carried out successfully, but nothing would be installed for the client to use. In the second example we would have the appliances and fixtures installed, meaning the customer would at least have something to use in their new kitchen. The second option helps me adapt to project changes more easily.

Now that i´ve explained to you both WBS scenarios I will show how I do my planning when working with Hybrid projects. I create my structure as Follow:

No alt text provided for this image

After splitting by smaller components I try to fit each delivery into sprints, so I can prioritize and organize my deliveries within the time box in a visual manner. Also let’s assume that my SPRINTS take 1 week each. I already know that my project is divided into 4 SPRINTS, so I can inform my client that the project will take 1 month to complete. Mounting the WBS in this way, I get the benefit to have a predictability about the project end date.

In addition to adjusting my deliveries in Sprints, I can define the MVPs (Minimum Viable Product) of the project, and by doing it, I can create the delivery milestones that my client can expect to receive beforehand, without having to wait 1 month to enjoy the benefits of a new refurbished kitchen.

Another major benefit of using a Hybrid WBS is improving communication with the project team. Sharing the WBS or putting it next to the Kanban wall is a way for all team members to inform themselves of the overall plan and delivery milestones for that project, at any time. I also have the habit to go marking an X for all the Stories that are being made, because that way I can track the status of the project and know if we are ahead or delayed on the deliveries.

If you want to find out about the road ahead, then ask about it from those coming back. – Chinese Proverb

WBS represents all project products and work, including project management work. In the example above I only demonstrated the Breakdown of the deliveries of the product but it is a good practice to insert the project activities, such as Sprint plannings, Retrospectives, Quality assurance, Risk management, Backlog grooming and so on … All work on the lowest levels must be associated with the highest levels, so that nothing is omitted or no extra work is performed.

The WBS is not built in stone and should always be subject to review by the Project Manager and Product Owner in conjunction with the team. I always revisit WBS in Sprint Planning, and encourage staff to review whether we need to break stories further or remove obsolete work packages, keeping the WBS version up to date throughout each Sprint.

I believe now that I have convinced you of the importance of maintaining a WBS, even if you manage small or open scope projects. Setting up a WBS is an activity that will not take away much of your time and the values it aggregates are immense as I demonstrated in this article.

A clever person turns great troubles into little ones, and little ones into none at all. – Chinese Proverb

In addition, the WBS serves as a baseline to my next article that will be about Prioritizing user stories. I will demonstrate how each User story can be weighted and mesured on its importance, relevance and urgency in the project, so that the PO can define the order that each one will be executed by the project team.

What do you think about this article? Did you like my WBS approach? Please leave your comments below, and until next Thursday.