Sprints at Scale: Working with 10, 100, 1000, or More Sprints in A Scrum Project

A Sprint is a mini-project and usually has a length of 2 weeks, though it can vary from 1 to 4 weeks. While running Sprints for a big project using Scrum framework, one can run 10, 100, 1000, or more Sprints. The number of Sprints goes-up when the Sprint length is shorter – say 1 week. This scenario highly possible.

Do not confuse Sprints at Scale with Agile at Scale, where multiple teams can work on multiple Sprints.

Now, questions can be:

• How do you manage so many Sprints?
• If you are using a software tool, how do you manage them?
• Is it possible to have the current Sprint being shown first in the tool?
  (with all other Sprints)
• Is it possible to show the work items for the current Sprint first?
  (a view showing all the Sprints)

These questions are very pertinent for any Scrum Master, Product Owner or an Agile Project Manager. In fact, recently I received such questions from Agile practitioners, who have been using my courses.

Let’s see how to manage a large number of Sprints and the answers to the above questions. 

Our Plan with Epics and Features

Our current plan is shown below and at a high-level:

• There are 5 epics, from Epic 1 to Epic 5.
• Each epic is broken into 10 features. In total, there are 50 features.
• These features will be associated with the respective Sprints. 
• One feature will be completed in one Sprint. For example, feature 50 will be done in Sprint 50. 

This is shown below in the Gantt Chart view of MS Project. 

These you can add in the Gantt Chart view or you can use the Sprint Planning Board or Sprint Planning Sheet views. 

As shown, we have features numbering up-to Feature 50. When you switch to the Sprint Planning Sheet, you will get the following view. 

Plan for the Sprints

To associate with Sprints, we need to create the Sprints first. These can be done using Project tab > Properties group > Manage Sprints command. 

As you can see, we have 50 Sprints planned now. 

Associate with the Sprints

One can use various possible views to associate the feature items with Sprint, but the most used ones (and recommended by my courses) are the Sprint Planning Board and Sprint Planning Sheet views of MS Project Agile software tool.

Using the Sprint Planning Board, for example, I’ve associated a number of features items as shown.

You have to simply drag and drop the items from the No Sprint column to the respective Sprint column. But then we have some constraints here!

• When it reaches Sprint 5, then the board view on the left does not show the feature items. If you have to associate with Sprint 50, then you have to drag it all the way up-to Sprint 50, which is on the extreme right.
• If you want to see only the last 3 Sprint items, i.e., Sprint 48, Sprint 49 and Sprint 50, then we also have to use the horizontal scrollbar to the end.

Hence, the better view to use in this case of having a large number of Sprints will be the Sprint Planning Sheet view. This is shown below. 

As shown, you have to just scroll down and associate the Sprint in the popped-up, drop-down or show-up list. Isn’t is very easy this way?

Show the Latest 3 Sprint Items first

Another issue is to show the last 3 Sprint items first. This cannot be done using the Sprint Planning Board view as the filters, groups are disabled in this view.

But you can circumvent it using the Sprint Planning Sheet view and applying the built-in Sprint group.  

Do note the change in order from from Ascending to Descending. That way, the latter Sprints will be shown on top. 

Sprint Grouped View

As you apply the above modified Sprint group, you will have the latter Sprints and the associate work items shown on top. The initial Sprints such as Sprint 1, Sprint 3 or Sprint 5, will be shown towards the bottom.  

Another Way to Show

Some of you may not want to apply to the Sprint group, but just want to see the latter Sprint items on top for quick usage. In that case, you have to change the sorting and sort it by Sprint ID as shown below. 

The Sort command dialog box can be seen by going to View tab > Data group > Sort > Sort By... command. 

Do note the change the order of sorting to Descending. That way, the latter Sprints and associated work items will come on top. 

When you apply this sorting, the Sprint Planning Sheet will come as shown below. 

As shown:

• The work items for Sprint 50, Sprint 49 and Sprint 48 are shown on top.
• The work items for Sprint 1, Sprint 2 etc. are towards the bottom.

In this case, we didn't apply any group, but just sorted items with Sprint ID field.

References

[1] Video Course: Mastering MS Project Agile, by Satya Narayan Dash 

[2] Certification Course: Certified Hybrid-Agile Master Professional (CHAMP), by Satya Narayan Dash 

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)

Troubleshooting in Lean-Agile Development

Many project managers utilize a Lean-Agile approach when there is high change or churn in project requirements, significant lack of clarity in scope, high complexity to their projects, and/or a larger number of risks associated with such. As these approaches have gained wide acceptance in a number of industry verticals, there has also been an increase in the problems being reported.

In this article, we will explore some of the practical problems faced by Lean-Agile practitioners during development of a new product or service and/or the building of a solution. When facing these challenges, Lean-Agile approaches have certain inherent or built-in mechanisms and execution best practices.

At this stage, I want to inform that problems and subsequent troubleshooting challenges the occur in a Lean-Agile approach can be divided into two broad categories:

• Iteration-based
• Flow-based

Two Lean-Agile Types

Earlier, in one of my articles, I had mentioned that Agile is both iterative and incremental in nature. We also previously explored the differences between iterative and incremental development with an example. I’m using the Lean-Agile approach here because many aspects of Lean are becoming increasingly a part of Agile (i.e., pull system, just-in-time planning, flow, visualization, waste elimination, error-proofing, and small batch-size, among others).

When I referred to the two Lean-Agile types, the categorization is based on an incremental delivery aspect. Let’s understand these two types a bit more.

Iteration-based Lean-Agile

In this type, the iterations are prescribed. Each iteration is timeboxed to the same size. Each timebox results in a working a set of tested features. The team pulls the item from a backlog of features, decides which can be delivered at the end of an iteration and usually provides an increment at the end.

An example of this type can be the Scrum framework. 

As shown in the above diagram, we have a number of iterations, and each iteration length is timeboxed to the same duration. 

Flow-based Lean-Agile

In this case, the iterations are not prescribed. Rather, the emphasis is on flow while having incremental delivery. The team pulls item from a backlog of features based on their capacity, and it’s not based on an iteration timeline. When the feature is complete, it can be delivered. It’s usually based on a cadence.

The number of features that can be taken on is based on a work-in-progress (WIP) limit. An example is the Kanban method, which has its original roots in Lean manufacturing.

As shown in the above figure, there is no regular timeboxed iteration, but incremental delivery can happen in cadence.

With these fundamentals in mind, let’s now explore the problems faced by Lean-Agile teams. In some cases, I’ll be using the terms Agile and Lean-Agile interchangeably. 

When the Product Owner is not Available Full-Time for the Team

This problem is predominantly seen in geographically distributed teams, where developers are working in one continent, but the product owner (PO) is operating from another. The product owner, while closer to the market, manages multiple products. This results in constraints because the PO is not fully dedicated to one team or present with them.

Any Lean-Agile team needs strong product ownership. This is crucial for success of the team and the product being built. The PO needs to be committed to the long-term objective(s) of the product (Product Goal or Vision) and continuously participating in the team’s project activities.

To resolve the problem of a PO being only partially available for the team, ensure that the PO is full-time, irrespective of the size of project or his/her location. An absence of this can lead to handicapped team performance and may even little value delivery.

To reaffirm, one of the principles of the Agile Manifesto is:

Business people and developers must work together daily throughout the project.

The PO can be the business owner or in some other structure, the PO can be paired with the business owner directly or via the Agile Project Management Office (PMO).

Nevertheless, the PO should be involved daily with the team members, not on a part-time basis. The PO is the team member who is responsible for the business success of the product. He/she is also accountable to the business. 

When There is too Much Complexity in Product Architecture

As noted in the beginning, Agile approaches are designed to tackle complexity, but sometimes project complexity can be too high and one may not know where to begin.

In such a case, one can use:

• The concept of Sashimi, or
• Take a tracer bullet approach

Sashimi is a Japanese word particularly used within the context of food. In Japan, a delicacy is thin slices of raw fish and sometimes served with rice—it’s called Sashimi. Each slice of fish is complete in itself, as well as tastes similar to other slices. This concept can be applied in Agile.

When using Lean-Agile approaches, we develop functionality that cuts across all the layers of a product, which has multiple layers – say front end, middleware, and backend. We are not developing the backend first, or the middle part or frontend. Rather, we deliver functionalities by cutting across all the layers.

The tracer bullet concept is based on the idea of firing in the dark! When you fire a gun in the dark, it’s difficult to aim due to the lack of light. However, when the path of a bullet is lit up (tracer bullet), you can see the trail and use it to inform your next aim. In other words, the tracer bullet helps to improve your aim for subsequent firing.

You can say, a tracer bullet of functionality is very similar to a Sashimi approach. We see the path of a bullet passing through all the layers or a functionality consisting of all the layers of a product. We are shown the path to build other functionalities. 

When Inaccurate Estimation Results in Delayed Delivery

This is another problem frequently seen irrespective of industry verticals. Developers, with all due respect to them, are generally optimistic people. The trouble is that when there are high uncertainties or complexities in a project, optimism may not be your best friend.

Estimates are often inaccurate because they are made in absolute numbers. For example, it will take five days to complete a feature/backlogged item or six hours to complete an activity.

One way to resolve this challenge is to use story points for estimation. Story points are relative estimation techniques and have unitless measure. Story points are relative estimates because they compare size, complexity, difficulty, and risks among other items being estimated.

To utilize story points, estimate the tasks (i.e., stories decomposed into tasks) into ideal hours. While the usual time unit used is eight hours a working day, it’s not always the case because of other activities such as meetings, unforeseen customer escalations, and interruptions, among others. When estimating using ideal hours, the time consumed for all non-productive, but necessary work is not considered.

This is depicted in the below figure. Ideal hours are considered here to be four/day. 

When Backlog Items are Insufficiently or Improperly Refined

Backlog refinement is a common practice and widely used in both iteration- and flow-based Lean-Agile types. The team starts off on the iteration or can take the item to the flow of work.

Let’s consider an example of an unrefined backlogged item: As a user, I can manage my settings, so that I’ll have the setting related information.

This is not exactly a small user story, but a very big one. In fact, this story can be decomposed further into three:

• As a user, I can manage my address details.
• As a user, I can set or reset my password.
• As a user, I can set my email preferences.

The address part alone comes with multiple parts, and a user has to utilize multiple operations to manage it. For example, add, edit, and delete. For this purpose, the product owner or product manager needs to have a good understanding of (user) stories, as well as refinement techniques.

To address this issue of improperly refined backlogged items, one can use the Definition of Ready (DoR) skill. Definition of ready is a checklist, which needs to be checked off step by step to see if the team has all the needed information before working on the item. DoR can be used before the beginning of the iteration or before taking a work-item into the flow of work. 

When a Deluge of Defects Occurs

There are many scenarios in which this can happen:

• Team is new to development
• The team has a lack of strong engineering practices, among others.

When the team is new to Lean-Agile development, it’s always a good idea to have training to understand the values and principles of Agile. The most difficult part, however, is the internalization of these values and principles (i.e., applying them daily during the project work). With a correct Agile/Lean coach, this understanding will be needed to sustain the project.

In addition, good engineering practices are not only necessities, but vital to stop deluge of defects and provide good-quality products. Some are noted below.

High test coverage and testing at all levels: You can implement high test coverage both at the system level, as well as unit test level, with automated test cases. The team should have testing at various levels, such as:

• Unit testing: Testing done at the lowest level.
• System testing: End-to-end testing of the full system or product.
• Smoke testing: Lightweight testing to ensure workability of the most important parts, and others such as black-box testing and regression testing.

Refactoring: Many associated refactoring is done within the context of software, but it can very well be applied to any product work. In fact, it’s a product quality technique with which you improve the design of the product through maintainability, but without changing the external behavior.

Simply put, with refactoring, you can change the internals of a product without changing the external behavior. With continuous refactoring, technical debt (i.e., legacy debt due to deficiencies in design, documentation, code (or product work), associated third party tools) is gradually reduced and defects are kept in check.

Continuous Integration: Any (product) increment given at the end of the iteration or continuously as in flow-based Lean-Agile, should be incorporated into the whole product. Post integration, the product still should work as intended.

Test first, develop next: In XP lingo, it’s called test first programming and in common Agile parlance, one can call it test-driven-development (TDD). Automated tests are written before doing the product work or creating the product. Next, work (or coding is software) is done to meet this test. This results in a built product with lesser defects.

Collective Ownership: In XP parlance, it’s usually referred to as share code. This concept says that the product work is owned by everyone in the team. You can also say, product quality is everyone’s responsibility. 

When Rework or Incomplete Work Happens

While working with an iteration-based Lean-Agile approach, an increment can be achieved on a cadence or on-demand. One the principles of the Agile Manifesto tells us this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or product).

If increments are not being delivered early and frequently, then the main purpose of going with a Lean-Agile approach is lost.

When the team delivers an increment, it must be fully “done” or complete. For this purpose, Definition of Done (DoD), an Agile artifact is used. Definition of done is primarily a checklist of items, which needs to be crossed-off, before a backlogged item or a story is considered finished.

To have proper work completion, the DoD should be exhaustive and clear. A sample DoD is shown in the below table. Only when a backlogged item has cleared the checklist of items listed in the DoD, is the work considered to be complete. Within this context, the issue of rework and/or incomplete work is addressed.

When Product Demonstrations or Reviews are Dysfunctional

While retrospectives are considered to be the most important practice in a Lean-Agile approaches, a close cousin is the practice of product demonstration or reviews. This is a very important event because Lean-Agile is fundamentally about value delivery to customers early and frequently, getting feedback, and customer collaboration – all of which happens in a demonstration or review collection.

While new teams can have failures during demonstrations, it’s also seen for experienced teams. Here are some situations that may occur:

• The (product) increment is not behaving as expected
• Features promised have been missing the demo
• The product crashes, or
• Worst of all – the PO and key stakeholders don’t accept the increment

Multiple dysfunctional product reviews can have a serious impact on the trust customers have in the team and equally, the self-confidence of the team who is delivering. To resolve this challenge, several things can be done.

Prepare early before the actual meeting: You should have a set of items or checklist of items prepared prior to the review or presentation. Not only should the team should take some time preparing for the meeting, but for an iteration-based type, they should use a checklist similar to the sample template below. 

Next, while running the meeting, document the decisions being made. This event, as noted before, also involves getting feedback from the customer/stakeholders and incorporating that feedback subsequently. With an eager clientele, a number of enhancements, new stories, or workflows will come up and it’s important that you note them.

Towards the end of the meeting, ask for acceptance on the increment. The acceptance may be conditional or there may be a time lag, before formally being accepted, but do ask for this, as it allows the increment to be released. This also tells the team that the increment delivered has met the definition of done (DoD).

Above all, never cancel the meeting. Sometimes it’s possible that you have very little to show or even that you know your product increment may crash. Still, go ahead with this event, as you will get feedback, and can make course corrections, if needed.

—

There are a number of problems or issues that can come-up while implementing a Lean-Agile development approach. In this article, I’ve outlined some of the challenges along with possible solutions.

What are the problems that you face? What approaches do you take to meet these challenges? Let me know in the comment section below.

--

This article was first published by MPUG.com on 9th March, 2021. 

 

References:

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

[2] Book: I Want To Be An ACP, The Plain and Simple Way, by Satya Narayan Dash

[3] Agile Practice Guide, 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