Ten Myths and Facts – Contingency Reserve and Management Reserve

 

Management Reserve and Contingency Reserve are two widely used reserves in Project Management, Program Management. It can also be used in Portfolio Management and Agile Management, though the way there are used will be somewhat different. However, there are many misconceptions about these two reserves. In this article we will see what those myths are and check upon the facts. 

These explained in my courses such as:

• PMP Live Lessons, Guaranteed Pass or Your Full Money Back
• ACP Live Lessons, Guaranteed Pass or Your Full Money Back
• RMP Live Lessons, Guaranteed Pass or Your Full Money Back

The needed content is also available as part of the PMP 35 Contact Hours, RMP 30 Contact Hours, ACP 21 Contact Hours and CAPM 23 Contact Hours courses. 

Note: First go through the myths on your own and try to answer yourself. That way you will get a better value from this article.

Hope you are tried to do the exercise on your own first! I'll also suggest that you go through this article to learn more:

Article - Contingency Reserve and Management Reserve

Now, let's see the myths and facts. 

Myth – 1: Addition of contingency reserve to activity cost estimates (or activity duration estimates) will create a rubber baseline. 

Fact: Contingency reserve can be at the activity level or work package level etc. If it’s at the activity level, then it need not be at the work package level. The reserves from lower level estimates will get rolled up to the work package level. Hence, there is no chance of having a rubber baseline. 

As you can see in the above block representation, the contingency reserve can be at the activity level, or work package level. Otherwise, you can have an overall contingency reserve at the project level.

Myth – 2: Contingency reserve is not applicable for the project schedule, it’s only for the budget.

Fact: It’s applicable for both project schedule and project budget. You can have contingency reserve calculation while determining the duration estimates of tasks or cost estimates of tasks. 

Refer to the previous diagram to see overall contingency reserve.

Myth – 3: Any reserve can be tracked with a reserve burndown chart.

Fact: Usually, contingency reserve is tracked at the project level, but management reserve is not. The reason is simple. Project Managers know and manage the contingency reserve as it’s part of the performance measurement baseline. 

So, the reserve burndown chart that one creates and manages at a project level is with respect to the contingency reserve, not for management reserve.

Myth – 4: If the reserve is unused, then it can be part of project profit! 

Fact: This is another big myth propounded. But you can’t take the unused reserve as part of the profit. It’s meaningless because you have added the reserve for unforeseen circumstances. 

• Threats – if the reserve is unused then, it has to be removed or given back. 
• Opportunities – if the reserve increases because you exploited the opportunity, then yes, for this you can consider it to be a profit.

Re-read the previous line! In risk management, both threats and opportunities are considered, but the way they are treated will be different. 

Myth – 5: Reserves have little to no role to play in S-curve interpretation. 

Fact: In fact, it’s the other way around. You should be worried when the reserve starts getting depleted while doing your S-curve analysis. The Budget at Completion (BAC) in earned value calculation should include the contingency reserve (CR).

Sometimes the estimate at completion (EAC) can go beyond the available contingency reserve and may eat-up the management reserve (MR).

                                                                

As shown in the above S-curve, the trend for Actual Cost (AC) curve is upward and it may consume not only the contingency reserve, but also the management reserve for the project.

Myth – 6: Slack or float can be a replacement for contingency reserve.

Fact: Slack and reserve are two completely different concepts. Many confuse the two. 

Total slack is about how much time you can delay a task without delaying the project end date. Free slack, simply put, is how much you can delay a task without delaying any successor task. 

Reserve or allowance on the other hand protects you against the delay in the current activity, not next activity’s start date! 

Myth – 7: Contingency reserve and contingency response planning are one and the same thing. 

Fact: Contingency as we know is the reserve for known risks, but unknown amount of rework. It’s for risks which are accepted or known risks with active risk response strategies. 

Contingency planning, on the other hand, consists of two plans: Contingency Plan and Fallback Plan. Simply put, these two plans are Plan A and Plan B, respectively that we use in our day-to-day risk management. 

Myth – 8: Agile projects don’t have all these reserves available.

Fact: In Agile projects, too, you may require contingency and management reserves. Consider an Agile project with mandatory regulatory requirements and one of the needs to meet the budgetary regulations with earned value calculations. In such a case, you need to have the reserves. 

Myth – 9: Management Reserve is a budget category, and not applicable for Schedules.

Fact: This is another myth, which is widely circulated. While management reserve is usually a budget category, you can also have it for schedule. In fact, the definition of Management Reserve as per the PMI-PMBOK guide is this:

An amount of the project budget or project schedule held outside of the performance measurement baseline for management control purposes that is reserved for unforeseen work that is within the project scope.

Can you see that the management reserve can also be part of project schedule (not just budget)?

Myth – 10: Contingency Reserve and Contingency are one and the same thing.

Fact: Contingency is an event or occurrence that could affect something, e.g., a task, a work package or the execution of the project. Contingency reserve, on the other hand, is the time or money allocated for known-unknown risks. However, contingencies can be accounted for with reserves.

There are many other myths, which circulate on these two reserves. What are the other myths you think are not correct for contingency reserve and management reserve?

If you have any questions, suggestions or feedback, do share your comments in the comment section of this article.

References:

1. PMP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

2. ACP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

3. RMP Live Lessons, Guaranteed Pass or Your Full Money Back, by Satya Narayan Dash

Agile Asanas: Closing A Project Vs. Closing A Sprint

 

Any genuine management practitioner will tell you that a project has to be closed, irrespective the methodology or framework being used. If it’s a traditional project and/or a project having multiple phases, then not only the project has to be closed, but each project phase has also to be closed. 

[ This post is part of the Agile Asanas series. 

To read all posts in Agile Asanas series, use this link. ]

Closing a project entails a number of activities and it’s advantageous for the project manager to do so. 

Now, because a Sprint is considered to be a mini-project, it also has to be closed, irrespective of the decomposition patten being followed such as:

• Project, Release, Feature, Sprint, Use Story
• Project, Feature, Release, Sprint, Use Story
• Project, Epics, Feature, Sprint, Use Story
• Project, Sprint, User Story

Going forward, I’ll be using the decomposition pattern of Project > Release > Sprint > User Story. 

Recently, I wrote a couple of articles regarding project closure and Sprint closure. I’d strongly recommend that you read both of them along with this piece. 

• Closing A Project – Hands-on and Step by Step
• Closing A Sprint – Hands-on and Step by Step

In this article, we are going to explore the differences between project and Sprint closures. For management practitioners, who want to be proficient across the spectrum of project life cycles and development approaches, it’s important that you know the differences.

*********

First the definitions. 

A project is defined by the Project Management Institute (PMI) as follows:

A project is a temporary endeavor to create a unique product, service or result.

Do note that the definition says that a project creates something unique. It can be a product, service result. This definition is not about a deliverable or increment at the end of the project – rather, it’s a finish product. 

I define Sprint as follows:

A Sprint is a time-boxed iteration event within the Scrum framework.

The Sprint event contains four other events: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Each Sprint can be considered to be a short project as noted in the latest Scrum Guide, 2020.

An increment of value is delivered at the end of the Sprint or prior to the Sprint. An increment is a step towards the Product Goal. You can learn more on increments and Product Goal in the below article:

Top Changes to Know for Scrum Guide 2020

With these foundational understanding, let’s see the differences one by one. 

Difference – 1: You close a Project once, but close Sprints many times.

A project is closed only once. If a project has multiple phases, then each phase is closed separately and these steps can happen multiple times. However, the project closure is the final one and happens once.

On the other hand, the Sprints are closed multiple times. After all, a project can have many releases, which in turn will have many Sprints. 

All these Sprints can be closed within the life cycle of a project. 

Difference – 2: Final increment is at the end of the Project, intermediate and/or multiple increments can happen anytime within a Sprint.

As we saw earlier, a project creates/builds a product (or service or result). Basically, it’s a deliverable or collection of deliverables. A deliverable is a uniquely verifiable product (or service or result) that is produced to close a project or phase. 

On the other hand, an increment (similar to deliverable) is produced at the end of the Sprint or prior, but within a Sprint. The increment given at the end of the Sprint is a sum of previous increments. An increment is not a finished product. 

Difference – 3: Resources are released when a project is closed. Resources are likely to remain when a Sprint is closed.

When a project is closed, all the resources are released. You, as a Project Manager, has to do it because you are accountable for the time spent and cost involved for the resources.

But when you close a Sprint as a Scrum Master, you don’t release the resources. Because those will be needed in the upcoming Sprints. 

Do note that in Agile, the team is cross-functional, self-organizing and self-managing, but procurement, hiring and release of resources (both human and non-human) are facilitated by the Product Owner and/or the Scrum Master. 

You can learn more roles being played in Agile and Traditional environment in the below article:

Agile Asanas: Mapping Traditional Project Roles to Agile Frameworks

Difference – 4: Final Report is given at the end of the Project, whereas usually Burndown Chart is enough for a Sprint end.

The final report given at the end of the project is quite exhaustive. This is the summary of project performance. It informs if the scope, schedule, cost and quality objectives are met, the achievement of business needs/objectives of the project, among others.

But, when a Sprint is closed, there is no such exhaustive reporting or documentation. Usually, Burndown Chart is enough to inform on the work completed. 

If you want, you can show certain additional information in your Sprint Report such as features completed vs features planned, velocity (story completed vs planned), issues faced, risks register and addressed. But remember, in Agile, one the values is this:

Working software/product over comprehensive documentation.

Difference – 5: Usually Projects will have Lessons Learned Meetings, whereas Sprints will have Retrospectives!

You may have noticed that Lessons Learned Meeting and Retrospectives are used interchangeably. But there are subtle and important differences. 

Lessons Learned Meeting is a periodic meeting, where the team meets to determine what they could do better in the future with a focus on improving team performance. Lessons learning happens throughout the life cycle of the project. However, the final Lessons Learning Meeting happens at the of the project. The ‘lessons learned’ is then archived into the organizational repository. 

Retrospectives, on the other hand, happen for the iterations or Sprints in our case. It has a recurring pattern and specificity. Here, the team meets how they can improve the process and product in the upcoming Sprints. 

Retrospective is a form of lessons learned meeting, but they are not the same.

Difference – 6: Project documents are closed and archived. A Product Backlog is not closed or archived. 

Project documents such as Requirements Documentation, Scope Statement (part of the Project Management Plan) are closed/completed/reviewed and archived at the end of a Project.

A Product Backlog used in a Scrum Project is not closed and archived when a Sprint gets closed. It’s a live document and continuously gets updated. 

In fact, at the end of the Sprint, the backlog is likely to get updated with the improvement items coming from the Sprint Retrospective event. Again, notice that it’s Sprint Retrospective, not Sprint Lessons Learned Meeting! I’ve already differentiated the two in the earlier point. 

Difference – 7: A project is a temporary endeavor with a longer time-span, whereas Sprint is a short time-boxed event.

This comes from the definition itself, which we saw earlier. A project is not timeboxed, i.e., when the time is over the project is over! The time-span of a project can be elongated or shortened. 

On the other hand, a Sprint is always a timeboxed event. If the Sprint duration/length is of two weeks, then the Sprint has to be closed at the end of two weeks. 

It doesn’t matter if the work taken to be completed within the Sprint is complete or not. It has to be closed! 

Difference – 8: Formal activities for contract closure happens at the end of the project, whereas contracts can be closed within a Sprint.

This difference is slightly tricky. 

At the end of the project, one considers both contract closure (all final payments made, no outstanding claims etc.) and administrative closure of the contract (confirming formal acceptance of deliverables, finalizing open claims etc.)

A contract can be closed during a Sprint when the deliverables have been given by the contractor and accepted. However, the administrative closure of the contracts can be time consuming and a Sprint is timeboxed. Hence, it’s not preferably done in a normal Sprint.

Difference – 9: Project Audits happen at the end of a project, but doesn’t usually happen within a Sprint.

The project audit is mainly to check the project success or failure. The success criteria are documented in the Project Charter document.

However, an audit usually doesn’t happen at the end of a Sprint. Audit is time consuming on its own and hence, a short time-boxed duration of Sprint can’t really accommodate the need.  

Also, as the customer (or proxy of the customer, which is the PO) is directly involved daily in Sprint, one need not go for an audit to check the success and failure for a project. 

--

Similarities

There are also similarities between the closure of a project and a Sprint. Below, I've noted some examples:

• Acceptance of deliverables/increments happens at the end. 
  For a Sprint, the acceptance (or rejection) happens in the Sprint Review event.
• The increment is handed over to the operations (in Project).
• In Agile, the increment is directly deployable and hence, usable or can be with the ops team (DevOps).
• Both Project and Sprint closures focus on value delivery.
  Increment must be of value to the end customer/user when delivered, so also a Project’s deliverables.
• A project can be prematurely closed, so also a Sprint.
• A project can be abnormally terminated, so also a Sprint. 

I believe with this you now have a fair understanding of the various differences between project and Sprint closures. If you have more things to add or have other comments and suggestions, do leave them in the comments section below.

References:

[1] ACP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] PMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

 

The Rhythmic Dance of Agile with Cadence

 

Odissi (pronounced o-dee-shee) is one of the classical dances of India from the coastal state of Odisha. Based on archeological evidence, it’s possibly the oldest living classical Indian dance. The Massachusetts Institute of Technology (MIT), US, notes in its web-archives that Odissi is two to three thousand years old. In recent decades, it’s been popularized by well-known artists—one being singer, Michael Jackson. In his famous 1991 song, Black or White, Jackson danced a fusion of Odissi and pop-rock, with his companion dancer, on the highways of the United States.

A unique dance position in Odissi is “tri-bhangi” (‘tri’ meaning three and “bhangi” meaning stance or position). Together, loosely translated, it means “thrice deflected stance,” and is quite difficult to master. In this position, there is a three- or tri-fold shape in the body forming an S-curve. To get into this stance, the upper part of the body such as head and hands are rhythmically moving in one direction, while the middle and lower parts of the body move in other directions with different rhythms. The joy of the dance for the viewer and performer alike comes through, in that parts of the dancer’s body are moving in rhythm, as well as the entire body moving, at large.

Now, you might be thinking what exactly a dance has to do with cadence in Agile?

Let’s start first with the definition of cadence.

Cadence – Definition and Basics *** UPDATED ***

One can define cadence in Agile as follows:
Cadence is a regular, predictable pattern of development work in Agile. It’s timeboxed and comes with consistent duration to help scheduling.  

Simply put, cadence is a rhythm of execution. The concept of cadence in Agile is suitably explained with a dance. With dance, art meets science, and in the same way, management meets life.

Like dance, cadence creates a predictable pattern of work or rhythm of execution.

Also, like dance, which can come with different rhythms for the different parts of the dancer’s body, cadence can be different for the different practices of Agile development. For example, you can have one cadence for Agile planning events, a separate cadence for Agile demonstrations or reviews, and a completely different cadence for Agile retrospectives. You can also have a single cadence for all events, for example, every two weeks, you may have planning, demonstrations, and retrospectives. We will explore a number of such situations shortly.

Taking another example from our own human bodies, many organs function in various cadences. For example, our heart beats on a cadence, our breathing or respiratory organ works on another, and so on.  In fact, if these vital organs of the body don’t operate on their respective cadences, life won’t exist!
That said, let’s explore how cadence can be applied in various Agile frameworks.

Working with Single Cadence
We have learned before, there can be two Lean-Agile frameworks at a high-level: iteration-based and flow-based. Irrespective of the type, cadence can be applied to development effort.

In iteration-based Agile, such as Extreme Programming (XP) or Scrum, an iteration length is prescribed. For example, in Scrum, where an iteration is called Sprint, the iteration length is usually less than a month (four weeks) as per my article on the latest Scrum Guide, 2020, and it’s always timeboxed.

When you keep the length of the iteration fixed over a period (and it is a good practice to do so), you develop a cadence. As we saw in our initial definition, it’s a predictable, regular pattern or rhythm of execution. When the iterations are repeated consistently over a period, a cadence is formed. In other words, in an iteration-based Agile, cadence is created with iterations, as depicted in the below figure.

Considering Scrum framework, the cadence is timeboxed, usually from two to four weeks and is created by a Sprint. Within the Sprint, you have a cadence, and it is a single one. When we modify it for Scrum, the figure will change to what is shown below.

Working with Multiple Cadences
Whereas in iteration-based Agile, the cadence is formed by iterations; in flow-based approaches such as Kanban, timeboxing is not prescribed. However, you can apply cadence here, too. You can choose when you do planning, when to release, and when to do a retrospective. You can decide on a set basis, such as a release every Friday, or you may choose an on-demand basis. It can also be based on when there is something valuable to release.

Below is an example of a team working with three cadences.

 

As shown above, we have:

• Every week the team releases whatever is ready for release,
• Every second week they have planning, and
• Every third week, they have a retrospective.

Working with Event-Based Cadence

A project manager could develop cadence based on events, as well. This approach is employed in flow-based Agile or, if the stakeholders decide to do so, in an iteration-based Agile. Below is a case depicting that. A planning meeting is started when the team runs out of items to complete. A release is triggered whenever the team has a set of features ready. A retrospective is done every two to four weeks.
 
Looking at the above figure, one could say that these are the event-based cadences:

• Planning Cadence: A planning meeting is started when the team runs out of items to complete.
• Retrospective Cadence: A retrospective is done every two to four weeks.
• Release Cadence: A release is triggered whenever the team has a minimally marketable feature (MMF) and/or subsequently, a set of releases.

Cadence and Project Life Cycle *** NEW ***
The cadence is quite important because along with development approach, it determines the project life cycle! In this case, I’m considering the delivery cadence. This is shown in the below figure. 

The delivery cadence informs how frequently the project deliverables are given. The deliverables can be given one-time (single delivery), multiple times (multiple deliveries), or periodically (periodic deliveries), among others.

Also remember that, development approaches can be many such as predictive (waterfall), adaptive (Agile) or incremental. A project life cycle can also be many types based on the development approaches. A project life cycle can be predictive, adaptive, hybrid (combination of predictive and adaptive) etc. You can learn more on development life cycle and project life cycle in this article.

Consider having a single delivery cadence, where the delivery will happen only at the end of the project. In such a case, one would go with a predictive life cycle. Similarly, considering multiple deliveries during development of software component for a car project can result in a hybrid life cycle.

Cadence and Intensity of Work
We know that an alert and healthy staff will always be more productive than if folks are tired or burnt out. For that, a sustainable pace is needed. However, in sequential/waterfall development model, this is not always the case.

Many times, it has been found that teams really can’t or don’t work with full productivity at the beginning of a project, especially, and it’s likely that they will start spending long hours and sleepless nights towards the end. In other words, the intensity of work goes-up towards the end of the project. Note the depiction of this in the below figure.
 

This late work towards the end of a project is known as death march, and it refers to the burnout and exhaustion of the team members. Obviously, this type of late work can lead to high attrition and the loss of talented resources. The Agile framework intentionally tries to put a stop to this risk. Hence, one of the principles of Agile Manifesto reads as:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

With short iterations, intense work doesn’t peak towards the middle or end of the project, but remains steady throughout the project’s life cycle. This is because a project consisting of multiple iterations, will have similar intensity densities.

Cadence – Advantages

There are many advantages of cadence, some of which are:

• It is easier for project managers to manage with an understanding of cadence in place. Imagine having twenty planning meetings for twenty iterations; with iterations operating at one-cadence, scheduling becomes less challenging.
• It builds muscle memory. When you have a rhythmic set of activities, it builds familiarity, and keeps the mind free of trivial (but, needed) details. When the mind is free of such, time is better spent on value-added work.
• There is a big reduction in coordination, which is an offshoot of the first advantage. Some critics of Agile say there is a large overhead involved, due to the need for coordination with short iterations. With cadence, this overhead is guaranteed to be less.
• Scaling the effort of Agile becomes easier. In scaled approaches, it’s usual to see multiple teams operating at the same cadence. Even if an iteration is cancelled or abnormally terminated, recovery is possible by going back to the cadence.
• As we saw earlier, with right cadence, the intensity of work remains even throughout a project.
  

More on the Topic of Cadence

As we reach closure of this article, I want to summarize the concept of Cadence used in flow- or iteration-based Agile with a video. It’s taken from ACP Live Lessons course. [Duration: 4m:26s]. This video uses a real-world example to explain the concepts I’ve written about above. For a better audio-visual experience, you may want to go full-screen with HD mode and plug-in your earphones.

Conclusion
The classical dance of Odissi starts with a solo form of pure-dance, where the performer emphasizes the execution aspect. It’s about knowledge, skills, dance patterns, and execution. The dancer, at this stage, excels with pure technical performance. In Agile methodology with daily cadence, the emphasis is also on execution–a bit of planning, a bit of design, a bit of development, a bit of testing, a bit of integration–daily. The individual developer is primarily involved in this technical work.

After the start, highlighting technical skills, we see the Odissi performer dancing with emotion, communicating feelings, and expressing nuance. Multiple dancers often come together at this point in the performance. In the context of Agile, within iteration (or flow) cadence, individuals come together to decide which items will be taken-up as they interact and communicate.

Next in the Odissi dance, it’s about group performance, or a team delivering together (i.e. they work on the whole drama part of the dance with a story). Similarly, in Agile, as the team comes together, delivery is made in release cadence. This can be after multiple iterations, every iteration, or on-demand. In most cases, these releases are given to the customer.

Finally, when pure-dance and dance with emotions combine with group-dance and delivery happens frequently, the Odissi dance becomes something else entirely. It is climatic, liberating, and often even stunning when this occurs. This stage is known as Mokshya in Odissi, meaning liberation or freedom.

In Agile parlance, this stage will be called a hyper-performing team, and it delivers highest-valued deliverables frequently, without interruptions. The team performs as a single, immutable unit, giving hyper-performances. While doing so, a constant pace can be maintained indefinitely. This is the essence of cadence.
 
* The opening photo of Odissi dance is by Bijay Biswal, who graciously agreed to share his ball-pen painting for this article and informed to be an honor that his painting is featured in the article.

—
This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away two years ago on June 11. He, along with my mother, introduced me to Odissi dance, taught me the importance of dance and music in our daily lives. It’s a tribute to them and their teachings. Men and women around the world have kept alive various forms of dance, which calms our minds and nourishes our souls. I take a bow.

--

This article was first published by MPUG.com on 29th June, 2021.

 
References:
[1] Online Course: PMI-ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash

[2] Online Course: PMI-ACP 21 Online Contact Hours, by Satya Narayan Dash

[3] Book: Kanban and Scrum, Making the most of both, by Henrik Kniberg and Mattias Skarin

[4] Book: I Want To Be An ACP, the Plain and Simple Way to be a PMI-ACP, 2nd Edition, by Satya Narayan Dash

[5] A Guide to Project Management Body of Knowledge (PMBOK), 7th edition, by Project Management Institute (PMI)

 

The Big Picture with Story Map in Agile Development

“I keep six honest serving-men,

They taught me all I knew,

Their names are What and Why and When,

And How and Where and Who.

I send them over land and sea,

I send them east and west,

But after they have worked for me,

I give them all a rest.”

– From the poem, “The Elephant’s Child,” by Rudyard Kipling

Long ago, in my childhood days, I was introduced to the fascinating world of poetry by my father, who brought a variety of poems and stories from writers and authors around the world to me. “The Elephant’s Child” was one of them.

This poem in particular has been used as a method. That is, the Kipling method. One of communication management, risk identification, charter preparation, and also, product development. With this method, one gets various ideas considering multiple aspects: What, Why, When, Where, Who, and How. It’s also known as the 5W1H method. In this article, we will learn about a technique called Story Mapping, where this method can be employed as an initiation point.

With the 5W1H method, when starting product development or creating a service or solution, one asks questions such as the following:

• What needs to be built?
• Why are we building it?
• For whom are we building?
• When will it be needed?
• Where does this fit in?
• How are the customers going to use it?

Jeff Patton, the creator of the User Story Mapping technique, explains the building of the map in six simple steps. They are:

• Frame the idea or problem
• Map the big picture
• Explore
• Slice out a release strategy
• Slice out a learning strategy
• Slice out a development strategy

The above 5W1H questions address the initial steps. It is important to remember that these questions get the conversations rolling. Shared conversations and shared understanding can then occur, as those aspects are what stories are mainly about.

Story Map Definition

As you may have noticed, this article is about Story Mapping, not User Story Mapping. There can be varieties of stories: spike stories, analysis stories, risk stories, and architectural stories, among others. I’ve seen all such stories being part of the map, and hence, will be using the term, Story Map.

Let’s begin with the definition of a story map.

Story map is a grid-like graphical representation of epics and stories in a sequenced order based on their business value and the order in which the stakeholders will execute them. When read from left-to-right of the map, it tells a big story in a sequence of steps, whereas when read from top-to-bottom, it gives more details about each step.

After you have framed the idea or problem with the 5W1H questions, you can begin to build a story map at a very high level with the help of above definition.

The customer, user, or subject matter expert may tell the story of the product being built in a sequence of steps. Each step is written on a sticky note, index card, or electronic card horizontally (from left to right). Then, under each step, the details are written on another set of cards, and this time, placed vertically from top to bottom. This forms a grid-like structure as shown below. This is a story map.

In his book, Jeff Patton calls the steps from left to right, “Activities”. Under each activity, you have a set of “tasks”, which you get when you break-down or decompose the activities.

As shown, the story is told by a user from left-to-right in a sequence of steps—each step being an activity. This sets the narrative flow. Under each activity, we have a set of tasks decomposed from the respective activity, and they are placed vertically from top-to-bottom.

With this basic understanding, let’s go a bit deeper and understand the various components of a Story Map.

Going forward, I’ll be using terms such as Epics (in place of Activities) and Stories (in place of Tasks), to maintain consistency with an earlier article on Agile development. In the real world, it doesn’t matter which terminologies you use, if you understand the concept and can apply it while building your product or solution. 

Building Blocks in a Story Map

Personas

The story telling for a story map starts with the persona. Persona is usually taken for a user, but in this case, I’ve extended it to stakeholders. The persona is an imaginary representation of the stakeholder role used while describing a story. You may express this element as the needs of an imaginary stakeholder. The persona can have likes, dislikes, a job, and goals, among other aspects. A persona plays a role in the organization—the role is real, but the persona is not.

The epics are considered from the persona’s perspective. For example, the story explains how the stakeholder is going to use the product or solution. Comparing a story map to a human being, you can say the persona will act as the head of the story map. The first thinking part starts here.

For story mapping, there can be many personas – not just one. This is similar to a human being who grows with input from many. When working with personas, a variety of stakeholders in various roles should be considered, who will interact with the product being built.

Backbone

Without a spine, a human can’t function, and similarly, without a backbone, a story map can’t function. The backbone provides the minimum set of capabilities needed to deliver the product or solution or service. This can also be called the minimum viable product (MVP). The backbone usually consists of features and epics.

Walking Skeleton

Just below the backbone, we have the map’s body part. The body consists of the walking skeleton. Again, making a comparison to the human body, you can say the walking skeleton is the story map’s skeleton, too. Just like the human body’s skeleton, without the walking skeleton, the product would be non-functional.

The walking skeleton is the complete set of end-to-end functionalities that make the product or solution acceptable. This part of the story map’s body usually consists of stories, including the user stories. This set of stories make the product minimally functional, and hence, can be called the minimum marketable features (MMF).

Under each story of the walking skeleton, you can have more stories arranged vertically. Higher priority stories will be at the top, whereas lower priority ones will be at the bottom.

When you combine the personas, the backbone, the walking skeleton, and the additional stories below the walking skeleton, you get the Story Map, as represented in the below figure.

The stakeholder starts telling the big story in a sequence of steps, which are represented as epics. This constitutes the backbone. While building the backbone, the principle of “mile wide, inch deep” or “kilometer wide, centimeter deep”, as Jeff beautifully puts it, is followed. It means we get to the end of the big story, before diving deep into the details.

The walking skeleton is below the backbone. When you decompose the epics in the backbone, you get the stories in the skeleton—ones that make the product minimally functional. Below the walking skeleton you have more stories, which are ordered.

Release Planning with a Story Map

After you have placed the epics, stories, and features in the story map based on the team’s capacity to deliver, releases can be determined. This is where the release strategy is sliced out from the story map.

As we already know, the backbone includes all the absolute essential parts of the product. These are items that you just can’t prioritize because they have to be in the product. Next to the backbone, we have the walking skeleton, which has the minimum marketable set of features. Hence, our first slice for the release consists of these two, and possibly some more stories, below. In the next slice (for another release), we can take more stories and create another release, and so on. This is shown in the figure. 

As you can see, in the first release we have the backbone and stories from the walking skeleton, along with one story below the backbone. In our second release, we have more stories taken, which are from below the backbone. Remember that these stories are ordered based on their business value.

Story Map vs Product Backlog

At this stage, you may be wondering why one should go for a Story Map rather than a Product Backlog?

After all, the product backlog also has all the epics, features, and stories in a single file. It can also have release slices. There are quite a few differences between the two, but I’ll note the most significant ones:

• While working with the product backlog, it’s easy to get lost in the details. Team members will be working on tasks, but they don’t see the big picture. You can literally miss the forest for the trees! With a story map, all members of the team see the big picture. This, in my view, is the most significant benefit of a story map over a product backlog.
• The story map is a two-dimensional visual structure, whereas the product backlog is a one-dimensional flat structure. Story mapping, on its own is also a prioritization technique—it’s just that it is done in a visual way.
• Dependencies can’t be easily shown in a product backlog as long as it’s a flat one, whereas dependencies can be represented visually and more clearly with a story map.

So, which should one use?

Note: You can learn the various differences between Story Map and Product Backlog in the below detailed post.

Agile Asanas: Story Map Vs. Product Backlog - The Differences 

The primary idea behind telling stories is communication. As noted earlier, it’s about shared conversations and shared understanding. You may think of using both the story map and product backlog in a single map, which is shown in the below figure.

The product backlog is just below the story map with a set of index cards or sticky notes, which are the backlog items. When needed, you can pull the prioritized ones into the story map. Don’t just go by the lumped-up cards in the backlog. Remember, you can order them as well.

It’s up to you as the Product Manager or Product Owner in consultation with your Project Manager and team members to decide which one best works for the team.

At this stage, it’s pertinent to note that like a Product Backlog which is never complete, a Story Map is also never complete. When new feature requests come up or enhancement requests are made, you can add, arrange, and order them within the story map.

A Practical Story Map

Let’s look at a real-world example to understand story mapping further. I’ll use my previous example of a flight ticket reservation portal, where I had explained various types of stories.

We will first start with the possible stakeholders (personas) who will be using this portal:

• Normal Traveler
• Business traveler
• Frequent Flier
• Booking Agent
• Vacation Traveler
• … you can add more.

You need not work on all of them, but can take just one to build the MVP consisting of the backbone and walking skeleton. For our example, let’s take the “Business Traveler.”

Considering the business traveler, we need to determine the big story in a sequence of steps. These steps will form the backbone or set of epics. These epics, when broken down, will provide the stories, which are listed next to them.

The epics are noted in the below table. Can you think of the associated possible stories?

Go ahead and try it.

The associated stories for the epics are noted in the below table. Your answer may vary, but you’re right if you tried to break-down and get to the related stories.

The above stories can be put in the usual story format. For example, you can say: “As a business traveler, I want to register via e-mail, so that I can sign-up for the portal.”

I’ve also noted the epics in the above table in single words. Search for a flight is simplified to “SEARCH,” select a flight becomes “SELECT,” and so on. This is for simplicity and to keep our high-level goals focused. When we take these epics and put them as a sequence of steps for the business traveler, we will get the following figure.

As shown, the story of a business traveler using the portal listed horizontally in a sequence of steps. The traveler will first sign-up, then search for a flight, and then select the flight. The traveler will pay for the tickets, and finally, close-out his/her interaction with the portal. These steps form our backbone.

Next, we will take the first big activity or epic, “SIGN-UP,” and arrange the stories associated with it vertically, as shown below. If you created your own stories, go ahead and put them below the respective epics within the structure of the backbone. This results in the walking skeleton and more stories below it.

Next, we slice out the releases from the map.

• For the backbone, we will have SIGN-UP, SEARCH, SELECT, PAY, and CLOSE.
• For the walking skeleton, we will have “new user registration” and “log-in” from “Sign-up,” “search by journey start/end dates” from “Search,” “Choose by shortest flight duration” from “Select,” “pay via credit card” from “Pay,” and “logout” from “Close.”

Your first release slice may look differently depending on the epics and stories you have chosen to start with. If your team has the capacity, take more. If this is the case, when you slice out the first release, it will result as shown below.

For subsequent releases, you and your team can decide which other stories are to be taken up.

That’s it! If you have understood so far and are able to slice out your first few releases in the map, you have understood the concept of story mapping well. It’s a long-read. But, I believe, if you have read it, worked on it, and gone through it honestly, it’s time to take a rest, as the poem I opened with says.

If you have comments, new views, or suggestions, do share them below.

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away last year on June 11. I miss him every day and feel his absence. He first introduced me to the world of poetry, stories, and books, so this is a tribute to him and his teachings.

--

This article was first published by MPUG.com on 23rd June, 2020. 

References:

[1] User Story Mapping – Discover the Whole Story, Build the Right Product, by Jeff Patton with Peter Economy

[2] I Want To Be An ACP: The Plain and Simple Way To Be A PMI-ACP, 2nd Edition, by Satya Narayan Dash

[3] The PMI Guide to Business Analysis, by Project Management Institute (PMI)

Work Breakdown Structure (WBS) in Traditional and Agile Life Cycles with MS Project

Work breakdown structure (WBS) is a key element for management planning, monitoring, and control of a project or a program scope. Regardless of the chosen life cycle (predictive, iterative, incremental, adaptive, or hybrid), WBS plays a role in almost every project. A WBS is important to further estimation—cost, duration, or resources, planning for resources, risk identification, schedule development, among others. It’s also used in earned value management (EVM).

In this article, I will cover the fundamentals of WBS with the definition, the key concepts which drive WBS development such as rolling wave planning and progressive elaboration, and best practices for using WBS in predictive (Waterfall) and adaptive (Agile) life cycles. I’ll also show how, with MS Project software, you can build a WBS in all possible project life cycles. We will conclude with the importance of a WBS in a project or program. 

WBS Definition

The project management institute (PMI®) defines WBS as follows:

A WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

The definition looks quite simple, but it’s a very significant statement for understanding the WBS. Let’s break it down.

• Hierarchical structure: The WBS is usually a hierarchical structure. It can present in a graphical format, tree form, or a tabular structure, but it will always be hierarchical in nature. The highest level of the WBS is known as Level-1 and followed with Level-2. It can continue to Level-N.
• Decomposition: The total scope of project work is considered and the team breaks down the work into manageable chunks. That’s why in the name WBS, we have a term breakdown. The decomposition or breakdown of the WBS creates the various levels, deliverables, and work packages. As you follow the breakdown, each descending level of WBS represents a further detailed definition of the work to be done.
• Deliverable: The deliverable is the unique, verifiable product, service, or result produced. The WBS is usually deliverable oriented when you do the decomposition. Based on the WBS, deliverables are created by the project team.

The previous statement of deliverable-oriented breakdown will enable us to understand how to actually break the project or program scope down to create the WBS. 

WBS Examples

Let’s take, for example, the writing of a book. Say you are writing a book on risk management. You want to have deliverables in terms of “Manuscript,” “Write Book,” “Edit Book,” and finally, “Publish Book.” Under “Write Book,” you have the individual chapters to be written (Chapter 1, Chapter 2, and so on). Similarly, under “Edit Book,” you’ll want to edit the individual chapters. In such a case, the WBS would be represented as shown. 

At the highest level, i.e., Level-1 (L1), we have the name of the book. In the next level, i.e., Level-2 (L2), we have the phases of writing, such as “Write Book,” “Edit Book,” and “Publish Book.” Next, “Write Book” is broken down into “Chapter 1,” “Chapter 2,” “Chapter 3,” and so also with the other WBS elements in levels. At the lowest level (L3), we have more details on each chapter (“Project Risk,” “Project Risk Management,” and “Agile Risk Management” and so on).

You may have noticed that I’ve assigned a numbering system to each element of the WBS, i.e., “1.2.2.2 Enterprise Risk Management.” The number used is the WBS identifier (ID), and is called the WBS code. This code or identifier uniquely identifies each element of the WBS. The WBS code is part of the WBS dictionary, which has detailed information about each element of the WBS.

But, let’s say you want to have a delivery in terms of your book’s chapters, i.e., Chapter 1 followed by Chapter 2, which in turn is followed by Chapter 3, and so on. In this case, the WBS would be shown as below. 

Can you see the differences between the previous WBS and the current one?

In the first WBS, the breakdown is in terms of writing the complete book, followed with editing the book, and finally, its publication. However, in the second WBS, the breakdown is in terms of writing, editing, and publishing individual chapters.

Depending on how you want to deliver, the WBS is built accordingly.

The lowest level of the WBS is known as the work package, where you can estimate for cost and duration. A work package is further broken down into activities, but these are not shown in the WBS, because activities are used in schedule management. The WBS can also have planning packages, which unlike work packages, are without the activities. Planning packages are put in the WBS for known, but unplanned work, whereas the work packages will have both known and planned work.

Above the work package level, there is a control account, where management control is exerted. The approved version of the total scope of work or scope statement, WBS, and WBS dictionary constitute the scope baseline.

At this stage, some questions may be coming to your mind:

• What should be done when one can’t decompose to the level of the work package?
• How can we implement further schedule or cost planning as they are based on the WBS?

This leads us to the concepts of progressive elaboration and rolling wave planning.

Progressive Elaboration and Rolling Wave Planning

Many management practitioners mistakenly think the concepts of progressive elaboration and rolling wave planning are only applicable in Agile environments. It need not be the case. In fact, these concepts apply both to traditional/Waterfall and adaptive/Agile projects.

Let’s first consider the definition of progressive elaboration. As per PMI:

Progressive elaboration is the iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available.

It’s highly possible that in a traditional project, there will be elements in the WBS which can’t be broken down further. As and when more clarity comes to those WBS elements, this can be done iteratively. This is progressive elaboration.

One key aspect of Agile development is its iterative nature. The concept of progressive elaboration fits with iterative development—more of which we will see shortly. Decomposition in an Agile project can happen with progressive elaboration, i.e., while building the product backlog, the backlog items are detailed progressively according to their priorities.

Rolling wave planning is a form of progressive elaboration. PMI defines rolling as planning as:

An iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level.

In Agile, rolling wave planning happens with project planning, release planning, and iteration planning. For example, while at the release level, the plan is at a higher level, and for the immediate next iteration, the plan is more detailed and granular. 

Agile – Iterative and Incremental

The Agile life cycle is both iterative and incremental, i.e., the product, result, or service is delivered in a series of iterations in an incremental way. To understand all possible life cycles in a project, refer to this article, Why and When to Go for Agile Life Cycle.

Let’s reuse our book example from earlier to understand how we can apply WBS in Agile mode. We want to write a book in an iterative and incremental way.

Iterative development is based on this premise:

We rarely get anything right for the first time, and it takes time to get anything right! Hence, iterate.

This is especially true in an environment when change is high, requirements are highly uncertain, and scope has differing perceptions among stakeholders. In such a case, we iterate. The focus in iterative development is learning optimization, rather than speed of delivery.

When writing a book, I wouldn’t complete ONE chapter in just one go. I would write, edit, delete, and rewrite the content of a chapter many times. The first version is usually a poorly written one, which gets better with feedback and iterations. In fact, while writing this article, I’ve followed the iterative mode of development, where I iterated the sections of this article multiple times.

Incremental development, on the other hand, is based on this premise:

It is better to build some of it (the product, service, or result) than to build all of it! Hence, deliver incrementally.

Again, taking the example of the book, I wouldn’t complete ALL the chapters in one go. Rather, I’ll write one chapter at a time and deliver it to an initial audience who wants to have a look. While editing the first chapter and writing the second, I’ll incorporate their feedback. The next chapter is built on top of the first chapter, and the subsequent chapters will be built on top of the previous ones – hence, the book develops in an incremental way. The focus in incremental development is speed of delivery.

While writing this article, I’ve also used incremental mode, i.e., I completed the first incremental cut and shared it with Jana Phillips, my editor. Jana has checked, added, and edited the article, providing me with her feedback. There may have been a new section added for the next incremental stage. In the final build, I’ll review it again and advise if anything more is needed. Finally, we go live with publication by the MPUG team (republished here).

Agile development combines and leverages both iterative development with improved or optimized learning and incremental development with speed of delivery. This is depicted below. 

WBS in Predictive Life Cycle

In a predictive life cycle model, requirements are fully known, change is low, and risk is also low. Hence, the phases in a project can be sequentially executed, though the final product (or service or result) is delivered at the end of the final phase.

Taking our book example, one can say the following phases of the project create the book. (I’ve made the phases a bit more formal compared to the previous example.)

• Research
• Design
• Development
• Delivery

With the adoption of these phases, the WBS will become as is shown below. 

At L1, you have the project name, i.e., “Book – Risk Management.” At L2, you have the various phases. The level-2 elements of the WBS are further decomposed to finally give us the work packages:

• “1.2 Design” is broken down to “1.2.1 Front Cover” and “1.2.2 Back Cover.”
• “1.3 Development” is broken down to “1.3.1 Write Book” and “1.3.2 Edit Book,” which are further broken down to the individual chapter level.

With Microsoft Project as your tool, you create and plot the WBS quickly as I’ve shown in the next figure. 

The default WBS code for the WBS elements (i.e., 1.1, 1.2, 1.3 …) can be shown by enabling the “Outline Number” under the Format tab. You can also create custom WBS codes with the help of this tool. The graphical side has various timescales, and, in our case, it has three tiers—the top tier in quarters, middle tier in months, and the bottom tier in weeks. 

WBS in Agile Life Cycle

In Agile approaches, the scope of a project is not clearly known from the beginning. It evolves throughout the lifecycle. All the requirements, features, epics, and stories for the project are part of the (Product) Backlog, as this article explains.

Though WBS is often associated with predictive lifecycles, in Agile approaches, WBS can be used. The scope of an Agile project is supported by the backlog. In Agile development, epics are decomposed into user stories, just like high level elements in a traditional WBS are finally decomposed into work packages. Also, as the work package represents the lowest level in a WBS, (user) stories will represent the lowest level of a WBS in an Agile project. In other words, you could say work packages in an Agile WBS will be equal to the (user) stories.

You may be wondering how to decompose from the project level to the user story level. There are many approaches, but for this piece we will explore a Project to Release to Iteration to (User) Stories scenario. The project is divided into multiple releases. Each release will have many iterations, and, in every iteration, we will deliver a set of features (an entire chapter, part of a chapter, or design of the book). The features can be estimated in story points. I’ve selected this decomposition approach to be consistent with my previous article on Agile Release Planning.

As we already know, Agile is both iterative and incremental. Hence, we have to deliver incremental value in every iteration. 

As shown above, at L1, you have the project name, i.e., “Book – Risk Management.” However, at L2, you have the various releases shown. The level-2 elements of the WBS are the further decomposed iterations (L3), and in every iteration, we will deliver the chapters (L4) estimated in story points. This level could be considered the work package level for this Agile WBS.

Like with the traditional WBS, with MS Project, this WBS can be as easily created. The software tool supports a Scrum framework, where iterations are known as Sprints. The created WBS is shown below. 

As shown in the above WBS, we have releases broken down into Sprints, and in each Sprint, we will be delivering a chapter or part of a chapter. This is a tabular view of the WBS and can be seen in Sprint Planning Sheet view.

You can switch to the Gantt Chart view to see the graphical depiction of the chart, which is shown below. 

Conclusion

While the scope defines the why of the project, the WBS tells the what of the project. It doesn’t inform how or when the deliverables will be produced or who will produce the deliverables.

The how part of the project comes later and is informed by the activities or tasks of the project. The how much part of the project also comes later and is typically addressed under the umbrella of cost management. The when part is best described by the project schedule. The who part of the project is addressed by resource management, i.e., the team members who will be executing the projects to give the required deliverables.

Nevertheless, it’s the what part of the project, the Work Breakdown Structure, which drives these other aspects—the how to do, when to do, how much money will it take, and who will do it. The WBS provides a clear vision of the total scope of work involved in a project and is the beginning stage of defining the deliverables—both intermediate and final deliverables—to be created. Due to its visual nature, the WBS is an effective communication tool used by managers in a project or a program.

--

This article was first published by MPUG.com on 18th August, 2020. This is a refined version.

 

References

[1] PMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] MS Project Live Lessons with Money Back Guarantee, by Satya Narayan Dash

[3] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)

[4] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

Videos Courses on MS Project Agile and Hybrid-Agile: 

[1] Mastering MS Project Agile (Scrum and Kanban) 

[2] Certified Hybrid-Agile Master Professional