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)

A Deeper Look: Top Changes in the New 2020 Scrum Guide for Agile Practitioners

A new version of Scrum guide was released in November, 2020. There are quite a few changes in the guide, as well as new additions. While the outline and structure of the guide have remained almost the same, as you go through the guide, you will immediately notice three high-level changes:

• The new guide is a much lighter and smaller version.
• It’s less prescriptive and seems to be intended for a wider audience group, particularly non-software users.
• It contains commitments for each of the Scrum artifacts.

In this article, I’ll outline the top changes and the deeper meaning associated with each change. My perspective is based on my analysis, my own interpretations, and the interactions I’ve had with Agile practitioners who follow my publications, books, and/or courses. 

Product Goal

The Product Goal has been defined clearly. It’s not an introduction because it existed earlier, but in the previous version, it was mentioned along with the vision.  

As per the guide, the Product Goal is the future state of the product. This definition of the ‘goal’ can create confusion for many who understand project-program-portfolio management and how goals aligns with the vision, mission, strategy, and objectives of an organization.

Ideally, the vision is the future of a product or program/portfolio or an organization. A vision is always associated with goals, without which a vision has no value or meaning.

However, as you look closely at the new guide, a big picture emerges:

• The Product Goal is the long-term objective of the team.
• A team works on and fulfills a single objective at a time.
• Before tackling another objective, the team has to fulfill (or abandon) the objective they are currently working on.

In other words, the goal is written with one or more objectives for the team. As the product roadmap is prepared, it gives further directional clarity to the product goal. The product goal should be linked to the strategic goals of the organization. One could summarize this by saying:

• The Product Goal is more strategic in nature, whereas,
• Sprint(s), mentioned as a project in the guide, will be tactical in nature.
• With each Sprint (iteration), the product moves closer to the product goal.

The Product Owner (PO) is the person who is responsible in building, and clearly communicating product goal to the team. The items in the product backlog (PBIs) should map to the Product Goal. Product Goal also reflects one of the values of Scrum: “Focus.” The team, as earlier noted, should focus on one objective at a time.

Now, you may be wondering what happens when multiple teams are working on the product backlog?

Regardless of the number of teams, there will be a single product backlog, a single PO, and a single product goal. This is depicted in the figure below.

 

Commitment based Artifacts

Now, every artifact in Scrum comes with a commitment.

The formal artifacts in Scrum are three:

• Product Backlog
• Sprint Backlog
• Increment

Now, all these artifacts come with commitments to ensure transparency and progress.

• For Product Backlog, the commitment is the Product Goal.
• For Sprint Backlog, the commitment is the Sprint Goal.
• For Increment, the commitment is the Definition of Done (DoD).

While Product Goal is newly introduced, Sprint Goal and DoD (earlier called “done”) existed earlier. In the new guide, all of these have found homes. For example, the home of Product Goal is the Product Backlog. 

At this point, it may be useful to note that “Commitment’ is also one of the values of Scrum, others being Focus, Openness, Respect, and Courage. Hence, one can say that commitment-based artifacts are reflections of one of the Scrum’s values. Commitments also increase “Focus,” another Scrum value.

I’ve mentioned the values here, because I believe they are very important, but you shouldn’t confuse values such as openness, courage, honesty, etc. with the value that you get while delivering an increment, although the latter is also important.

As the saying goes, “Culture eats strategy for breakfast.”

In my view, it’s actually the values and value-system which eat strategy for breakfast. Strategy execution is the downstream of culture. Culture is the downstream of human, team, or organizational values. And values are the downstream of the philosophy on which civilizations (or a team/organization) is based.

At times, values are thrown around like punchlines, brandished as political weapons, or misused for self-serving interests. It’s true adherence to values that really matters because without values, nothing really works. This is true for a person, team, organization, or even a civilization.

As we proceed through the other changes, I’ll continue to reflect on the Scrum values. 

Multiple Increments

Earlier it was mentioned that an Increment will happen at the end of Sprint. Now, within a Sprint, multiple Increments can happen.

An Increment happens when a backlogged item meets the DoD. Hence, an Increment can be created at any point of time during a Sprint. This is depicted in the below figure. 

As shown, at the end of the Sprint, we have Increments. Increments can also happen at any time during the Sprint. The new guide clearly informs that Sprint Reviews should not be considered “gates” for releasing value.

As there can be multiple Increments, the sum of all these Increments are presented to the (key) stakeholder at the Sprint Review. 

Introduction of Cadence

For the first time, we are introduced of a concept called “Cadence.”

This is an important introduction, which is missed by many Agile practitioners. Cadence is used in other Agile frameworks such as Kanban, and is basically a rhythm that gets developed as one continuously follows a set of events over a period of time.

In Scrum, the cadence is provided in the form of five events:

• Sprint – the container event
• Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review – the contained events within a Sprint

I’ll suggest that you read this change along with the previous change of “Multiple Increments.” As you go through these updates together, you can see two things emerge:

• Development is happening in cadence, whereas,
• An Increment can be there at any time during the Sprint.

You can say development (or build) of the product and incremental delivery have been decoupled. In fact, they can be thought to be of two streams as shown below.

As shown, the stream for cadence is decoupled from the stream for increment. The diamond shapes in the cadence stream denote the Sprint Reviews. While there is an increment at the end of the review, on-demand increments can happen at any time, as we see in the increment stream.

Cadence helps with inspection, which is one of the pillars of empiricism. This, in turn, drives another value of Scrum: “Openness.” 

Lean Thinking

Earlier the guide referred to empiricism. Lean thinking has appeared for the first time.

Empiricism is a practice which is based on knowledge coming from experience and what you know or have observed. The three pillars are: Transparency, Inspection, and Adaptation.

To include and encourage lean thinking, the wording in the guide has changed in quite a few places. For example, the guide notes: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” Again, remember that “Transparency” (or Openness) is one of the values in Scrum.

A key principle of lean thinking is to avoid “Muda,” a Japanese term meaning “waste.” When work is not done after being taken into a Sprint, the result is Muda. With DoD, Muda is avoided. Do remember DoD is the commitment for an increment. With DoD:

• You know exactly what it means to have an increment.
• The team is compelled to complete the items taken, not start taking new items.
• One can say it’s about: Start Finishing, Stop Starting.
• From that perspective, some elements of Kanban have been absorbed into Scrum.

Introduction of “Why” in Sprint Planning

Other than “what” to do in the Sprint and “how” to do it, the “why” aspect has been introduced.

Earlier, before the start of Sprint Planning event, two questions were emphasized:

• Topic – 1: What should be done in this Sprint?
• Topic – 2: How do we do it within the Sprint?

In the new guide, emphasis has been given to Sprint Goal. Hence, we now have three aspects:

• Topic – 1: Why is this Sprint valuable?
• Topic – 2: What should be done in this Sprint?
• Topic – 3: How do we do it within the Sprint?

This is shown in the below figure. 

Sprint Goal has to be collaboratively defined by the entire team. The introduction of Sprint Goal in the Sprint Planning event, reemphasizes a value of Scrum: “Focus.”

Single Scrum Team

Earlier, there was a Development Team within the Scrum Team. There is no ‘team within team’ now.

A Scrum Team is one, and it consists of the Product Owner, Scrum Master, and Developers. This is a step away from the “us-vs-them” mentality created with the term “Development Team” earlier. It also avoids a “throw-over-the-wall” mentality (i.e. my or my group’s work is done and now is the time to throw it over the wall, so that the other group takes care of it!)

Now, the team is considered to be a cohesive unit of people focused on the Product Goal. The PO, SM, and Developers are all intrinsic parts of the Scrum Team. The new version of the guide also notes that the team is the fundamental unit of Scrum.

The single Scrum Team concept enables two values of Scrum: “Respect” and “Openness.” With a single team concept, there is less likelihood of “us-vs-them” mentality.

Also, a single team concept with no hierarchies creates a culture where everyone knows that the team succeeds or fails together, hence candor goes-up. It’s likely to stop compartmentalization of members, prohibit group or community biases, reduce politics, and cripple finger-pointing, and eliminate blame-games and back-biting. If one team member is failing, it means the whole team is likely to fail with their ability to meet the goals of Sprints, the goal of the Product, or the honoring the DoD. The team moves towards, or strives to be, an indivisible whole.

Self-Managing Team

Instead of “Self-organizing,” the team is now “Self-managing.”

Agile teams are cross-functional meaning that they have all the needed skills to do the work and create value in each Sprint. Along with that, whereas the team was described to be self-organizing in the earlier edition, the terminology has now been changed to self-managing. There is a subtle difference between these two terms. Self-managed teams go one step ahead of self-organized teams.

A self-organizing team chooses who will work and how to do the work. A self-managing team, on the other hand, chooses who, how, and what to work upon. In my view, the team can consider the new aspect of “what,” because the PO is now explicitly part of the team.

It’s not that a team will be self-organizing from Day 1 or even within a few weeks of interactions. The team has to go through the stages of team formation, such as forming, storming, norming, and performing.

Also, with the introduction of “what,” the team decides which items are to be taken-up for the next Sprint. This, in turn, reflects another aspect of Lean Thinking: “Muri,” another Japanese term meaning “overburden.” As the team decides what items are to be taken-up, Muri is less likely to arise. When what items are determined at the beginning of the Sprint, it reflects another aspect of lean thinking: Just-in-time (JIT).

Not a Servant Leader, but a Leader who Serves

The Scrum Master being referred to as the Servant-Leader of the team has been removed.

The guide currently notes, “The Scrum Masters (SM) are true leaders who serve the Scrum Team and the larger organization.”

This enables the SM to play a larger role in the organization. The SM is not only now accountable for establishment of Scrum, the SM also leads, trains, and coaches the organization on Scrum adoption. He or she also advises the organization on Scrum implementation.

In my view, this is a positive change because I’ve noticed that the words, “Servant Leader,” have been weaponized by some teams. The SM is not a clerk or secretary to take notes during Sprint events and send meeting emails or reminders. The role of a SM is much bigger with a focus, not only on the team, but also playing a broader role in the organization. This larger aspect is emphasized by putting leadership first.

—

As you go through the new guide, you may also notice changes such as:

• The three questions of Daily Scrum are no longer mentioned.
• One process improvement item from Sprint Retrospective, which must be taken into the next Sprint’s backlog is no longer there.
• The term “useable” has been used in place of the term “releasable,” among many others.

In this article, I’ve elaborated on some of the top changes. I hope you are not only aware of these, but understand the deeper, philosophical reasonings behind these changes in the Scrum framework.

--

This article was first published by MPUG.com on 29th December, 2020.  

References

[1] Online Course: PMI-ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

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

[3] The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland

Understanding Velocity in Agile Approaches with MS Project Agile

There are certain questions that usually surface in almost every project regardless of the type, domain considered, technology used, complexities associated, or strategic significance. These questions are:

• When will the project be completed?
• What are the items you can deliver by the end of the project?
• What are the items the team can take for the forthcoming release or iteration?

These questions fundamentally boil-down to the schedule of the project, and what and when the team can deliver over this schedule. As you can see, the first question is about the duration of the project, the next is about scope, and the final one asks about plans to be delivered.

In Agile approaches, the concept of velocity helps to address such questions. In this piece, I will start with the basics and dive a bit deeper to help you understand this concept. Towards the later part of this article, I will show you how to calculate velocity with MS Project. I will conclude with certain key characteristics. 

Note: For hands-on, in-depth understanding of velocity and associated concepts, you can refer:

• Mastering MS Project 2019 Agile

With this course, you will know various aspects of velocity such as writing features in as stories (will convert to velocity), velocity histograms,  Sprint/iteration velocity, Release velocity, Release velocity along with Sprint Velocity, among others. 

Basics of Velocity

Velocity is the measure of product backlog items (PBI) delivered in an iteration. It’s the rate at which the PBIs are delivered, validated, and accepted according to the definition of “done,” per iteration. In other words, you can say that velocity is a measure of a team’s rate of progress. You sum up the PBIs delivered and you get velocity. If the item is not completed, it won’t count toward velocity.

The PBIs in a backlog can be features, bugs, enhancements, spikes, and refactoring, among others. You may consider all of these as part of velocity or decide to include some. Irrespective of the decision you make along with your team, it’s important to always maintain transparency on this topic.

Let’s explore an example to understand velocity better. Let’s say that in an iteration, your team delivered PBI-10, PBI-11, and PBI-3, which are estimated at 3, 8, and 5 story points, respectively. Velocity for the iteration would be 16 or 16 story points, as calculated below.

Velocity = Estimate for PBI10 + Estimate for PBI11 + Estimate for PBI3

Velocity = 3 + 8 + 5

Velocity = 16 (or 16 story points)

If you have an incomplete item, it won’t be considered for velocity calculation. For example, if PBI-11 remains incomplete at the of the iteration, the velocity will be 8 or 8 story points.

So, how does velocity help in answering the questions raised earlier, those of when the project will be complete and what items can be delivered?

Going back to our example, let’s assume the product backlog has 200 points worth of work, your velocity is 20 points per iteration, and each iteration has two-weeks duration.

Number of iterations needed = 200 / 20

Number of iterations needed = 10

We will be needing 10 iterations or 20 weeks to complete the work items in this backlog. If you start working on the backlog during the month of January, you will be able to complete it by end of May, which is shown in the below figure.

Velocity in Ranges and Confidence Levels

It’s possible that velocity can fluctuate for a team over the duration of a project or release. Considering our previous example, it can be as low as 15 (minimum) or as high as 25 (maximum).

No one exactly knows what the future entails. There can be inclusion of new high priority items, a change in a 3rd party component which introduces a number of bugs, or changes in team members for the project, etc. Hence, it’s a good practice to calculate the velocity range, in place of thinking of it in absolute numbers. For example, you can say that the team’s velocity range is between 15 to 25 story points. With this approach, you are conveying that it’s an estimation and nothing is absolutely certain.

Next, let’s see how the duration changes with range in velocity numbers. With a velocity of 15, you will be needing around 14 iterations to complete (200 divided by 15 and rounded it to 14) the backlog items, whereas with a velocity of 25, the team will be needing just 8 iterations to complete the project (200 divided by 25). In the first case, it will take seven months to complete the backlog. Whereas in the latter case, it will take four months. You can graphically represent it as shown in the below figure.

 

Our velocity estimation can be refined further by looking at confidence intervals. For example, you can say the team can complete the initial 80 points with 90% confidence, whereas the next 70 points worth of work can be done with 50% confidence, and finally, the last 50 points worth of work with 10% or with very little confidence.

Why provide the confidence levels? So that work items towards the bottom of the backlog are not clearly defined and estimated, i.e., they are coarse grained, and very big–usually epics. Estimation for such work items will be 40, 80, or 100 story points. As you can see, confidence levels helps in setting proper stakeholder expectations. 

Why the Term “Velocity”?

As I teach and interact with Agile practitioners, I get asked about the terminology of “velocity” often, and why it’s not called “speed”? After all, it’s the rate of progress or the items a team has completed in an iteration, which, in a way, informs the speed of delivery.

There is a subtle difference between speed and velocity. Speed is a scalar concept, whereas velocity is a vector concept. Speeds tells how fast you are moving or covering a distance, whereas velocity tells how fast you are moving in a particular direction. Speed is direction agnostic, whereas velocity is direction aware.

Some may also ask, what direction is the team moving towards when the term “velocity” is used? The direction is propelled by the product vision. The vision of the product (or service, or result), to be delivered by the project, is outlined in the beginning stages of the project. Vision tells us for whom the product is being built, what purpose it’s going to serve, and what benefits it will deliver with one or more compelling differentiators. With every iteration (or Sprint, if considering Scrum framework), you are moving one step closer to this vision/goal of the final product. Metaphorically, velocity is an apt term in place of speed.

Estimating Velocity

In our first example, we saw a velocity of 20. You might be wondering how I arrived at this number? This question leads to velocity estimation. Velocity can be estimated in a variety of ways. Let’s check a couple of them. 

Using Historical Information

Historical information can be gathered from similar, previous projects in the organization. When you consider historical information, there should be little (or almost no) variations among team capability, technology and domain used, product owner involvement, etc. This technique is useful when your team is totally new to the project.

There can be drawbacks with this technique because it’s not the current team’s own data, and when actual velocity comes up, estimated velocity may not match with historical information. One could say that using historical information is a type of Analogous Estimate.

Observing Actual Velocity

In this approach, iterations are actually run to determine the velocity. The team usually runs at least three iterations and then determines the average velocity.

Compared to the previous approach of using historical information, velocity is calculated actually using the real data. There can be drawbacks to this approach, such as  business executives finding it difficult to wait for at least three iterations to get an estimate, or a duration estimation needed even though the project may not be executed immediately. In such a case, you can have a forecasted velocity.

Whatever approach you may take to estimate the velocity, following are some practices worth noting:

• Discard historical information when you find the actual velocity.
• Calculate the average velocity, but communicate in ranges.
• Update the velocity at the end of every iteration.

Working with MS Project 2019 Agile

Both Scrum and Kanban don’t have any concept of velocity as a practice or a framework concept, but velocity is a widely used metric by many Agile teams and many software tools. MS Project software, which supports both Scrum and Kanban, doesn’t have velocity as an explicit metric. However, you can easily determine velocity with few customizations.

By way of illustration of this, we will use a Scrum framework and follow four steps. 

Step – 1: Create Needed Custom Fields

Product backlog items can be features, bugs, enhancements, and even documentation related to the work. For the sake of our example, I’ll only consider the features which will be estimated in story points. In our case, we will create two custom fields:

• Feature (flag) – a Boolean/flag custom field. If yes, then the PBI is a feature; otherwise it can be any other PBI type.
• Story Points – a number custom field, as story points are calculated in numbers. If you are not going with story points, you can have feature points or simply, points.

When you create the custom field for “feature,” it shows as captured below:

When creating custom field for “story points,” ensure that the calculation for rows and summary tasks is rolled-up. This is depicted in the below figure: 

Another custom field is needed for velocity calculation (a number customer field), which we’ll simply call Velocity. The velocity will be calculated only if the PBI is a feature and it is 100% complete. This you can translate into a formula.

Note that for this velocity custom field, the calculation for rows and summary tasks is rolled-up. This is depicted below.

Step – 2: Use the Built-In Groups and Filters

The MS Project software comes with a number of built-in groups and filters. We will take one such group, Sprint.

Before applying the grouping, we have the following Backlog with items distributed across various Sprints. You can drag and drop the backlog items and put them into respective Sprints as shown in the Sprint Planning Board view.

In the Sprint Planning Sheet view, we have the following depiction. As shown below, the items are populated with the values in the respective fields.

We have story points estimated for PBIs, and a field for whether the PBI is a feature. The PBI priority has been set with product prioritization techniques, used by Product Managers.

Apply the in-built group: Sprint, which results in the below view.

Step – 3: Calculate the Story Points for a Sprint

As shown in the previous figure for individual Sprints, the story points have been cumulatively added and rolled-up to the Sprint level. For example:

Sprint 1:

• Three features, “Log into the online trading system,” “Create a new user,” and “Buy a stock,” are estimated at five story points (SPs), 8 SPs, and 5 SPs, respectively.
• Add them together, and we have a total 18 story points worth of work.

Sprint 2:

• Three features, as well, are: “Logout of the system,” “Sell a stock,” and “Transfer a stock,” each of which are estimated at 5 SPs.
• As you add them up together, we have a total of 15 story points worth of work.

Similarly, it’s for the other Sprints and the entire product backlog, which has, in total, 208 SPs worth of work. 

Step – 4: Determine the Actual Velocity for a Sprint

The final step is to calculate the velocity for the Sprint. For this purpose, we will add the velocity custom field, which we created earlier.

As the team starts sprinting and completes the features, only then will the velocity field be populated. Let’s say at the end of the Sprint, the team has completed all the features. The velocity will be 18, as shown the below figure.

Characteristics of Velocity

In conclusion, I will summarize certain key characteristics associated with velocity, as follows:

• Only completed and accepted work is counted towards velocity.
• Velocity is a measure of output (the size of what delivered, such as a 20 story points delivered). It’s not a measure of outcome (translating to value).
• It’s an empirical observation of the team’s capacity to complete work per iteration. As noted earlier, even though you use historical information, discard that immediately as soon as you have actual data to work with.
• Velocity is comparable across items for a given team on a given project. For example, while you can compare the same team’s velocity over iterations, you can’t compare two separate teams’ velocities.
• Velocity is not a measure of productivity, as that would be a trap and a subjective estimate, not an objective one.

You may also like:

• Agile Asanas: Key Guidelines to Follow for Velocity (1)
• Agile Asanas: Key Guidelines to Follow for Velocity (2)

--

This article was first published by MPUG.com on 3rd March, 2020. This is an updated version with latest MS Project Agile features.

—

References:

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

[2] Video Course: ACP Live Lessons, Guaranteed Pass, by Satya Narayan Dash.

[3] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, by Satya Narayan Dash.

[4] Video Course: Microsoft Project Live Lessons, 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