Agile User Story (The Complete Guide 2019)

Agile user story

Agile user story

Within an Agile context, user stories are the primary currency used to determine what needs to be built by the team that represents customer value. User stories describe functionality that will be valuable to a customer and user (in other words, persona). 

In this blog, we explain 40+ New Agile Hacks for creating Agile User Story with new templates 2019.


The product owner is responsible for eliciting user stories from customers and stakeholders and identifying them in decomposition exercises such as story mapping.


Many others, however, may contribute user stories to the PO, including the team and the sales and marketing departments. The PO collects and adds user stories into the backlog.


Those user stories that are rank-ordered highest within the backlog get selected and built within a sprint or are the next to be pulled. The attempt is to build user story functionality within a sprint or approximately a week time box.


Other Attributes of a User Story

Attributes of a User Story

A user story is complemented by several attributes besides the acceptance criteria. These attributes help you describe the scope, ownership, and progress of the story. They may include the following:


1. Comments: any decisions or details that have an impact on the “how” to build it based on grooming and planning discussions.


2. Size: a place to include the size, typically in story points.


3. Tasks: decomposition of the user story into bits of work that represent an incremental build of functionality. They may be nested in a story or linked as individual children record to the user story.


4. Owners: members of the team working on the story. There should be at least one developer and one QA tester.


5. State: the status of the work such as open, in progress, resolved, verified, and done.


Decomposing Ideas with Agile Story Mapping

Decomposing Ideas with Agile Story Mapping

Why Decompose Ideas

Decomposing big, bold business ideas means slicing smaller increments that have customer value. It is a critical activity performed by Lean and Agile organizations. It is the core of what happens in the Refine stage of the enterprise idea pipeline,


There are many reasons why you would consider bringing your big business ideas to market incrementally. At a high level, the arguments fall in one of two buckets: market reasons and technical reasons.


On the market front, the pace of change in customer tastes and in the availability of competitive products to satisfy those tastes has never been so fast, and it is accelerating.


Can you believe that the ubiquitous iPhone is, as of this writing, not yet a teenager? In a world where change is the norm, the past is no longer a reliable predictor of the future.


Logical deduction alone cannot identify which products or solutions your customers will adopt. But applying experimental thinking can help you discover them.


From a technical perspective, enterprises that participate in the creative economy never build the same thing twice. Indeed, when something has to be done more than once, it gets automated. Therefore, enterprises are usually solving problems that are new to them. Your own enterprise may be like that.


This begs several questions. Do you have the technical capabilities to build the product? Can you do it at the speed that meets customer expectations and at a cost the enterprise can afford and customers can accept?


Uncertainty surrounding an enterprise’s ability to deliver can be just as great as that surrounding market demand. This uncertainty demands a discovery mindset. Experimentation is core to discovery.


Because success is not guaranteed, you must have the ability to run multiple experiments. These experiments should be short and inexpensive, yet yield as much information as possible.


Experimental thinking is critical to the enterprise. The Refine stage of the enterprise idea pipeline is dedicated to cleverly decomposing big, bold business ideas into smaller increments.


Exploring Story Mapping

Exploring Story Mapping

In the words of Jeff Patton, the person credited for formalizing the practice, “Story maps solve one of the big problems with using user stories in Agile development—that’s losing sight of the big picture.” He also calls this problem the “tragedy of the flat backlog.”


A story map is a visual representation of the user journey your enterprise seeks to bring to life.

It’s a summary and reminder of the story you tell one another about what you are building, who you are building it for, what value the users will get, the options you have in satisfying user needs, and so on. Story mapping supports and promotes the conversation. It does not replace it.


A good way to see how story mapping works are to go through a simple example. You’ll first see the steps from beginning to end. Later on, you’ll get some practical tips on how to execute those steps.


As an example, let’s imagine a bank that has a very basic mobile banking app. Customers can view balances and transfer money between accounts. Now, the bank wants to add bill payment capabilities to the app.


How could the bank limit its investment, particularly in software development, to discover whether its customers are interested in such a capability?


The story map will make the options clearer. While this example is about augmenting an existing customer experience (the mobile banking experience), the same concepts apply to greenfield initiatives.


Can Story Mapping Help You Build a Better Story?

Story mapping

Decomposing big ideas into smaller increments allows you to better navigate the uncertainty inherent to the work of the creative economy. A useful increment seeks to validate customer value. It will do so quickly by being as small as possible. Incorporating customer feedback reduces the uncertainty surrounding the value of the big idea.


Story mapping helps you validate the hypothesis of customer value as well as the assumptions that underpin that hypothesis. You may find that it is useful during conversations to call out the primary persona.


Understanding who the idea is for helps with the customer experience and the types of feedback loops that can strengthen the experiment. Getting all the brains to contribute is one way to manifest more of the collaborative Agile mindset.


Consider exploring story mapping. Which idea is your enterprise thinking about trying next to deliver value to your customers? How could you apply story mapping to deliver value or test critical hypotheses sooner?


Connecting the Idea Pipeline to Backlogs

Connecting the dots, whether through people, process, or technology, can help you understand how all the pieces of the work are intertwined, what you can do to optimize the flow of the work, and ensure you are actually working on customer value.


Mechanisms such as technology and process can help you connect ideas that are valuable to work that will make its way to teams’ backlogs.


Connecting to Backlogs

Connecting to Backlogs

Work comes into the backlog from several sources. The main source should be from the idea of increments or feedback from customers. When you start a story mapping session, it's unclear what the result may be until you cut the first increment. You connect the dots by listening to everyone in a divergent mode and converging to an increment of work.


There is a lot of storytelling going on during story mapping, where you consider what story the customers are telling us they experience the idea. In making storytelling a collaborative session, we effectively ask participants to listen to multiple options and connect the dots to a meaningful end-to-end slice.


The challenge in connecting the dots between idea and user story is that you start with an idea that can have multiple options and directions. In the middle of a story mapping session, it can be quite nebulous as to how it may end, and it is important to be comfortable with this uncertainty. The end result is a collection of epics and user stories that are added to a backlog(s).


The penultimate backlog is one that virtually supports all levels of requirements elements across your requirements tree.


Through the use of filters and tags, you can instantiate any level of requirements you’d like to visualize such as a portfolio view of all ideas (or at least the highest-value ideas), an idea or product view, or a team view.


What you really want to highlight is what parts of the idea are actually being worked on. It would be great to be able to click an active idea and instantly see what user stories are actually being worked on that support that idea.


Types of Backlogs

Scrum board

There are many forms of backlogs. They can be in the form of a Kanban board or Scrum board. Traditionally, backlogs are aligned with teams and called product backlogs or team backlogs.


These backlogs are usually filled with epics, users stories, and tasks. Agile teams use backlogs to help drive their work. All backlogs in Agile are meant to be prioritized. The following are examples of several backlogs.


An enterprise idea pipeline is a form of a backlog. The difference is that the enterprise idea pipeline focuses on the portfolio of ideas as they come into the enterprise, and it tracks progress from the Record stage to the Reflect stage.


Stakeholders of value (product owners and chief product owners as well as business, marketing, and senior managers) use this backlog to prioritize by value and drive investment decisions.


A product backlog is a backlog of work that revolves around a product, service, or idea. The PO owns it. While anyone can add work on the product backlog, only the PO can prioritize it. Work that comes from decomposing the idea is placed in this backlog if it is product-centric.


From there, it is often groomed to add detail and better understand the work. Those user stories that are at the top of the product backlog are of high priority and are ready to be pulled and worked on.



team backlog

The team backlog represents a view of the work that is geared toward a particular team. During grooming and sprint planning, the team hones the work in their prioritized backlog. From that, the team can establish a sprint backlog of those high-priority stories they will work on within a sprint.


While technically a story map provides a view of the current and future work much like a backlog. More importantly, a story map provides a third dimension to the backlog by providing the customer experience view of the work ahead. It is important when story mapping is being used to connect the idea to the story map to the backlog.


The story map used for an idea should continue to live as additional increments are considered and additional options in the form of epics and user stories are generated to populate the backlog.


Attributes of Backlogs

The beauty of a backlog, whether an enterprise idea pipeline or a product backlog is that you can enhance it with attributes that can help you sort and understand the requirements within.


Attributes are characteristics that can help you find distinctions among requirements. An example of an attribute is a priority. By including an attribute that helps you consider the importance of requirements, you are able to sort the requirements in order of importance, allowing you to focus on the high-priority requirements.


There are many types of attributes that can be included in your backlog to help you manage the work. These attributes include the following:


Requirements Types: a way to differentiate among requirements types such as ideas, increments, epics, themes, user stories, tasks, and defects.


  • ID: a way to provide a unique identifier for each requirement.
  • User Story: a requirement that includes who wants it (personas), what they want, and why they want it.
  • Details: information learned during grooming and planning including decisions.


  • Acceptance Criteria: the conditions that satisfy a requirement typically at the user-story level.
  • Source: the origin of the requirement, such as customer, stakeholder, or strategy.
  • Priority: a way to differentiate the importance of the requirement, often written as high/medium/low or must have/should have/could have/won’t have.


  • Sizing: a way to indicate the amount of work involved in a requirement often specified in story points (for example, 1/2/3/5/8/13/20).
  • Complexity: the factors and risks involved in completing the work written as high/medium/low. Can impact the size of the work.
  • Dependencies: a way to indicate when a requirement is dependent on other requirements or external items.


  • Progress: the current status of the work. May also include the history of the item.
  • Owners: the team members who have volunteered to do the work.


Considering Dependencies

Considering Dependencies

Managing dependencies is a big part of running an enterprise. Similarly, managing requirements is often an act of managing dependencies. Some work is required in order for other work to complete. Other work may be needed to complete an end-to-end view of the work.


Be aware of lower-value work that may be dependencies. If a high-customer-value user story is the next requirement to get pulled for work, you may learn upon grooming it that it depends on lower-value work getting done first.


In this case, either the lower-value work inherits the higher value or you continue to keep it as lower value and create the dependency link.


Importance of Grooming

Importance of Grooming

Grooming or refining is the process of honing user stories to gain a level of detail and get them ready for sprint planning. In relation to customer value, while technical details will be discussed, the key focus in grooming should be the business details on why an epic or user story is needed.


When there is a strong understanding of why something is needed and in what business context, the team is able to make more context-specific technical decisions to support the customer need. The business context and reason may be inherited from the story map or idea itself if properly explained.


There are a number of benefits for grooming sessions. Since grooming typically occurs prior to working on the requirement, it allows time for the new work to “sink in” and to mitigate risks, and it gives the PO time to address unanswered questions. It also provides a short window where the work is headed.


During grooming, the focus should be on the higher-priority work for the simple reason that it is better to put the effort in the highest-value work and not waste time focusing on lower-value work since you may never get to it.


The PO is primarily responsible for the grooming event. The PO should invite the full team and include others such as marketing and business leaders who may have a business context. Most importantly, the team can ask the PO tough questions regarding specific information and acceptance criteria to gain relevant details about the story.


What does a grooming event look like? It may last a couple of hours when the user stories are reviewed in priority order.


Each story may be focused on for about five to ten minutes with the goal of gaining a better understanding of the work, starting with understanding the business reason for the work. The better you groom the higher-priority items within the backlog, the easier and shorter the sprint planning event will be.


While grooming, you may focus on breaking epics into user stories, ensuring user stories are in canonical form, adding business and technical detail, identifying dependencies, understanding acceptance criteria, identifying unknowns and risks, capturing what is out of scope, and optionally considering sizing. Finally, you may mark stories ready for sprint planning or ready for work.


How Well Connected Are You to Your Work?

customer-value work

A big part of helping employees see the full picture of customer-value work is the ability to connect the dots from when ideas come in all the way down to the user stories and tasks.


This may not be as easy as it seems since enterprises are rarely one transparent, end-to-end requirements canvas where you can see the full requirements tree in one space.


Do you have people, processes, and technologies that can help you “connect the dots” across your requirements landscape? Can you be sure that the ideas of the highest customer value are being worked on?


Can you see the user stories that help build the increment of an idea? Connecting the ideas to your user stories provide transparency to your work, a view of what work is getting attention, and the assurance that the user stories connected to the highest-value ideas are indeed being worked on.


Collaboratively Engaging the Team

Collaboratively Engaging the Team

The collaborative conversation goes beyond those internal to the enterprise. As discussed the customers and their feedback loops add to the collaboration. The internal focus brings the idea to fruition with healthy conversations to understand customer needs.


The external focus involves customers to gain their important feedback to determine if you are moving in the direction of customer value.


There are debates as to how many team members should be involved in story mapping or grooming user stories. My answer has always been all of them. For grooming user stories, this is the team. Having the whole team collaborate through the process eliminates the need for sharing second-hand information.


For story mapping, the caveat is that you may do it in stages if there are more than ten people involved. The reason is to keep it active and engaging while allowing everyone to participate. For grooming and sprint planning, having the whole team collaborate ensures a greater understanding and applies the brainpower of everyone.


Top Branches of the Requirements Tree

Top Branches of the Requirements Tree

A more detailed definition of an epic, user story, and task as they relate to building new ideas follow.

An epic is the parent of multiple user stories and is roughly equivalent to a function, feature, or very large user story that encapsulates a large piece of functionality.


Epics are typically written by the PO but may be contributed by other stakeholders or may result from a story mapping or other decomposition session. They should be decomposed into user stories before being introduced into a sprint.


A task is the child of a user story—a very small unit of work—and is equivalent to an incremental decomposition of the user story that the team defines. The intent of tasks is to allow the team to incrementally build and test the story so that not all testing occurs at the end.


Avoid decomposing stories into the stand-alone design, develop, and test tasks, which emphasize a mini-waterfall approach. Instead, the tasks of a user story should incrementally build upon each other.


For example, a user story that builds a search function (for instance: As a user, I want to search available mortgage options so I can determine which will be the least expensive) can be decomposed into the following:

  • Create a static Web page to hold my results
  • Build a simple search with available mortgage companies
  •  Add advanced search capabilities with interest rate options


There are other types of work items that should be captured in the backlog. Extreme programming introduced the spike solution, which provides a focus on solving a challenging technical, architectural, or design problem. Known as a research spike, this work may seek the answer to critical business or technical issue.


Two examples of research spikes are “What database solution will the team use?” and “What is the product direction in applying forums?” The answers serve to support subsequent epics and user stories.


Promoting Agile Budgeting

budgeting framework

At its most simple form, a budgeting framework is a means to establish where money gets spent in an enterprise. A good budgeting framework applies a demand system like an idea pipeline where ideas collect.


On a regular basis, it assesses the demand based on customer value and enterprise strategy, and then it aligns the supply side to meet the demand.


In many organizations today, budgeting is a yearly affair. Budgeting starts by soliciting ideas, often referred to as projects, that are collected over a period of several months.


[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


Why Agile Budgeting?

Why Agile Budgeting

The overall theme of Agile budgeting is for an enterprise to use its money more wisely as it adapts to customer needs and the marketplace. This starts with having an enterprise idea pipeline and stakeholders that readily accept and evaluate ideas as they enter the pool of ideas in the Reveal stage.


This effectively eliminates the annual budget process wait states that can make an idea irrelevant and it helps you optimize the flow of getting the idea to market much more quickly,


A more customer-value-based approach is to pair the Agile budgeting frame-work with the enterprise idea pipeline and lightning-bolt-shaped teams. The advantage is that you can use these concepts as a way to ensure you align the people and teams (in other words, supply) with the most valuable ideas (that is, demand) on a continuous and flexible basis.


Imagine a scenario where the enterprise idea pipeline has a number of very high-value ideas waiting in the pool during the Reveal stage. As part of the Reveal stage, it is discovered that the top idea requires help from three teams to work on that idea. When you look at the capacity of those teams, the third team is full and cannot pull any more work in.


Now you have two choices. You can ask the third team to evaluate if this new idea is of higher value than their current work and, if so, gracefully wrap up or cut the tail of the work as quickly as possible.


Alternatively, if you see that the third team is consistently the bottleneck to pull in high-value work, then maybe it is time to add people to the team or create another team that can fulfill that type of work.


The benefit of having an enterprise idea pipeline is that you can visually see high-value ideas waiting in the pool (demand) and the utilization of teams (supply).


The benefit of having an Agile budgeting framework is that you can actually do something about it. You can move the budget to the teams that have more high-value work flowing their way and reduce low-value work.


Structuring around High-Value Ideas

Structuring around High-Value Ideas

The primary theme behind an Agile budgeting framework is to use your money more wisely by enabling effective investment decisions. Investment decisions should focus on matching the highest-customer-value idea (demand) with the earliest possible moment a team can work on it (supply).


A portion of an enterprise’s investment will focus on running the business activities such as maintaining an enterprise’s critical business operations along with maintenance and support.


Hopefully, a greater portion is spent on investing in ideas focused on growing existing products and services and ideas focused on transforming and innovating the business. An Agile budgeting framework considers all three areas (run, grow, and transform).


Your goal should be to have all teams working on the highest-value work. However, it is not unusual to see some teams working on low-value work.


Keep in mind that demand, whether in the form of ideas, features, or bug fixes, will typically outstrip supply, which is the teams that do the work. Because there will always be lots of “work,” it is important to ensure that the work that your teams are doing is, in fact, of the highest value.


Those Involved with Agile Budgeting

 Agile Budgeting

Agile budgeting requires an enterprise to turn its big upfront, the event- a driven process into small incremental and continuous sessions. This can be a significant shift for some organizations since it moves concerted effort from one part of the yearly calendar and spreads it out across the year.


There may be a shift in roles and responsibilities in implementing an Agile budgeting framework. 


The key stakeholders involved with Agile budgeting are the owners and stakeholders of value (for example, product owners) and senior management as the owners of the strategy. This group may be called the Agile budgeting team or whatever term suits your enterprise. Avoid any terms with existing baggage.


If there is a portfolio management team, its responsibilities may move away from decision making and instead focus on enabling Agile budgeting by collecting data to gauge customer value and sharing it with the Agile budgeting team.


A portfolio management team can help those evaluating an idea and its value by considering strengths, weaknesses, opportunities, and threats (also known as SWOT) as well as focusing on the trade-offs of comparing ideas that may increase revenue, protect revenue, reduce costs, and avoid costs.


If there is a project management office, the responsibilities may move from ownership of the work to enabling Agile budgeting focusing on dependency management among the ideas. The key takeaway is that the decision makers of a customer-value-driven approach, the owners of value, become the drivers of an Agile budgeting framework.


Avoid making a new idea the highest priority because someone says so. An Agile budgeting framework attempts to avoid prioritization based on HiPPO (highest paid person's opinion), where a senior manager makes priority calls based on his or her opinion. This can lead to chaos and a lack of understanding where the higher-value work resides.


While the Agile budgeting framework helps you more quickly course -correct toward customer value, it can be prone to chaos if many course changes occur with little discipline in understanding customer value.


In the spirit of ownership and self-organization, as enterprises move responsibility to the level that has the most information typically across the enterprise onto teams, senior management should have more time to evaluate ideas based on value and alignment to strategy.


Lightning-Bolt-Shaped Teams

Lightning-Bolt-Shaped Teams

An Agile budgeting framework can initiate a need for how an enterprise is structured and how employees are educated. Since customer value changes over time, it requires an enterprise and its employees to adapt to that change.


The goal is to be able to move the high-value work readily and quickly with-out extensive reorganizations of the enterprise. The key is to avoid an overly rigid and inflexible enterprise structure.


While reorganizing an enterprise can help it align to customer value, another approach is to extend team skills so that you can experiment with and apply the “move work to the team” approach.


This advocates investment in building lightning-bolt-shaped teams willing to learn more. These are teams where each team member has a primary skill, secondary skill, and tertiary skill as it relates to the work.


To create a lightning-bolt-shaped team takes an investment in education to instruct each team member in a secondary and tertiary skill.


For example, developers have a primary skill of programming code. As a secondary skill, they learn how to build database schemas and, as a tertiary skill, they learn to write unit tests and run test cases.


As another example, developers have a primary skill of programming front-end user interfaces in HTML and JavaScript, a secondary skill programming API routines and protocols, and a tertiary skill writing back-end applications in Ruby and Python.


The long-term benefit is that if the team members can develop additional skills, there is a greater likelihood that a team can work on a much wider range of ideas while being kept together longer, allowing the organization to gain the benefits of a high-performing team.


This can reduce disrupting high-performing teams and increase the ability to build high-quality ideas.


Agile Budgeting Framework

Agile Budgeting Framework

Agile budgeting requires an enterprise to turn its big upfront, event-driven process into a small, incremental, continuous process. This can be a big shift for some organizations.


It is best to avoid a big-bang approach when moving to an Agile budgeting framework. If you have an annual budget process that is being used, it is best to pick the next quarter to get started.


In this first quarter, allow yourself the three months to experiment with an Agile budgeting framework and tailor it to your enterprise.


Review the “Components of an Agile Budgeting Framework” section and use the time in this first quarter to experiment and set up the framework. Remember, since your enterprise size and complexity is unique, how you might implement Agile budgeting will vary according to your context.


In this first quarter, introduce education for key stakeholders as owners of value and strategy (Agile budgeting team) on what is Agile budgeting, including the Agile mindset focusing on getting to customer value and the Agile values and principles.


Conduct a separate session on incremental and experimental thinking with a special focus on challenging assumptions, Cost of Delay (CoD), and CoD divided by duration (CD3). This session should include discussions on feedback thinking and establish customer feedback loops to validate customer value along the way.


Introduce the enterprise idea pipeline and the way you plan to capture the idea (for example, canvas) and value (for instance, CoD and CD3). Set up your enterprise idea pipeline and decide what you plan to call it within your enterprise context.


This setup includes moving your current-and-not-yet-acted-upon ideas to the board that makes up your enterprise idea pipeline.


With a small group, preferably product owners, attempt to calculate a CoD and CD3 value for each idea. Include a list of assumptions used to calculate CoD and CD3. Once you complete this with a subset of ideas (less than 20 ideas), share with the Agile budgeting team.


Set up a working session with the Agile budgeting team to walk through each idea in rank order according to the CD3 value score. Share your assumptions.


Ask the Agile budgeting team to use open-ended questions to challenge assumptions. These may include the following: What led you to that conclusion? What do you think the level of uncertainty is?


What is your riskiest assumption? and What information do you need to validate this? This last question is critical and can help you consider the focus of your first increment of an idea and feedback loops to help you validate customer value. This is the time to wrestle with and understand this framework.


As people challenge assumptions or present the value scores, listen for people attempting to get their ideas in their area or division to have higher value scores.


This is where the mindset of focusing on customer value becomes important. The objective is to optimize for the greater good of the enterprise and not sub-optimize for a particular division or individual.


After a couple of sessions with the Agile budgeting team, you will have an updated list of rank-ordered ideas according to a value where assumptions have been challenged. Now start the ignition of the Agile budgeting framework.


Share top ideas with teams that would work on the ideas. This is the transition from the old framework to the Agile budgeting framework. Ask the team(s) when they think they can pull a high-value idea, cut an increment, and begin validating the customer value.


What you may encounter is that some teams have a backlog of ideas and work that is overflowing. The POs of those teams will need to make value calls as to what is more important—the existing work or the new work. Often you may find that the existing work, while deemed important, has a lower value than the new work. Expect healthy debates.


Cadence for Curating Ideas

Cadence for Curating Ideas

Once you have a good handle on your Agile budgeting framework and have tailored it to your enterprise, it is time to begin a periodic cadence for curating the ideas.


Identify a schedule to hold the Agile budgeting sessions based on the pace of ideas coming in. While many ideas may come in, a healthy session evaluates just the higher-value ideas, as these are more likely to be working in the near future.


You need to identify the owners of value and strategy (that is, the Agile budgeting team). You may find there are more people in the session that are necessary. If possible, you need to keep the participants to fewer than 12 who can speak. Otherwise, the session can become unwieldy.


Value of Metrics

Value of Metrics

A metric is only as valuable as your ability to digest it and use it to steer your enterprise. Some metrics have temporary use while others may have a more permanent use. You may observe that although many metrics are created and shared, only a few of them are actually being used for decision making.


You have to continually ask what measures can help a team or organization move in the right direction? Before discussing suggested metrics, it is worth having a discussion of the relative value of a metric.


The value of a metric is defined as its usefulness divided by the effort it takes to collect. The dividend implies the metric serves a useful purpose, such as decision making.


The divisor implies the metric costs, which are the energy in collecting data and generating the metric. If the usefulness is outweighed by the energy to generate it, then it may not be worth preparing the metric.


Some metrics may have a short life cycle, being valuable for only a certain time based on the usefulness they provide.


As an example, if an Agile education program commences, it may be of value to collect the number of people educated in Agile. This provides visibility into ensuring the actual number of employees being educated is increasing as desired.


However, once you have educated 80% of the target audience, it may no longer be used to collect this data and keep tracking this metric.


Because of the relative value of metric changes over time, it is beneficial to periodically assess the value being generated. If a current metric no longer provides value, it is time to retire it. If a new one is of value, it may be included if the usefulness outweighs the energy to generate it.


Value of Leading Indicators

Business success

Business success is measured in a number of ways. When you think of desired outcomes from a customer perspective, it is more products sold or used, meaning an increase in revenue. Having a customer revenue metric helps you understand whether products or services are being sold.


Capturing revenue is a good starting point. However, because revenue is an outcome metric, it is a lagging indicator. To supplement lagging indicators, you need leading indicators that provide you visibility into what is currently occurring with the customer and the progress of the idea.


This timely visibility is important because it provides input for making better decisions as you move forward. Better decision making with timely data leads to an increased chance of success and more revenue.


While customer revenue is an important metric to collect, the question is, what metrics can you put in place to ensure you are moving in the right direction?


For every lagging metric, you need to establish at least one leading metric to act as an indicator to provide visibility to gauge if you are moving in the direction of a positive lagging metric (for example, increase in revenue). I call this the lagging to the leading metric path.


Since this is a lagging metric involving revenue from customers, leading indicators could be the following:

  • Customers attending demos: a leading metric involving the demos or sprint reviews. You capture how many customers are attending the demo and feedback you are receiving. If customers aren’t attending, there is a reduced probability that you’ll reach the successful outcome you desire.


  • Customers satisfied with a demo: a leading metric where you capture customer satisfaction from the functionality viewed in the demo.


  • Customers participating in beta: a leading metric involving how many customers are willing to exercise an increment of an idea in a beta environment.


The value of leading indicators is that they “indicate” if you are moving in the direction of customer value.

If no customers are willing to attend a sprint preview of a product, this indicates that maybe the product is not appealing to the customer marketplace. With no customers, you also miss the valuable customer feedback to help you adopt toward customer value.


If customers are reporting negative satisfaction in the sprint review, this indicates that the idea is not appealing to the customer marketplace. Finally, if a few customers are willing to participate in the usage of an idea increment in a beta environment, this can indicate little customer interest in your product.


The key is building a set of leading indicators to help guide you since no one indicator provides all of the data you need.


HR as Promoters of Agile

HR as Promoters of Agile

As you move your enterprise toward an Agile mindset where employees matter, there should be a shift where HR becomes a coach and mentor for employees.


While there will still be senior team members and managers to grow teams, HR can provide a bigger view of employee needs, looking for patterns as they build enterprise employee programs.


HR must be continuously in touch with employees through a number of vehicles such as 1:1s to help grow and coach individuals to Open Space Technology activities where dozens to hundreds of employees share their thoughts and ideas to support their well-being. HR can be the coach for advancing self-management and servant leadership within a company.


Experimenting with Motivation

Experimenting with Motivation

HR can become leaders, innovators, and promoters of experimentation within their companies in regards to HR practices.


What is becoming clearer is that traditional HR practices and programs have less of an appeal to the younger population of employees and traditional performance management systems haven’t been particularly successful in motivating individuals.


Business thinkers, like Daniel Pink in his blog Drive, emphasize intrinsic motivation factors over extrinsic factors. Pink argues that the use of reward and punishment is antiquated. He proposes that you adapt your thinking to include autonomy, mastery, and purpose.


It is important for HR leadership members to experiment with and experience this new way of thinking so that they can identify what sorts of motivation will raise employees’ happiness and morale and bring more productivity to the enterprise.


Since there should be a strong focus on employees in an Agile-focused enterprise, applying a discovery mindset in HR can set the tone for the behaviors that you are looking for in employees. HR may include employees in their experiments for what works best in an enterprise. Will 360 -degree performance reviews work?


What type of questions should you ask when hiring for an Agile mindset? Do team-based performance goals continue to motivate an individual team member?


Facilitating Open Space

Open Space Technology

Open Space Technology (also known as Open Space) is a method that enables self-organizing groups focused on complex themes or problems in a short period of time.


Open Space is a way to initiate what is termed as unconferences, which avoids a lot of upfront planning. For HR, the theme or problem is how to create better performance excellence or employee well-being system.


An Open Space agenda is emergent as a number of topics may be addressed and surface during the start of the session. You can share a theme and ask for topics or problems around that theme. Attendees then gather around the topics they feel are a priority and provide thoughts, ideas, and solutions to those topics.


In learning Agile and Open Space methods, HR can act as facilitators for Open Space sessions and support teams who may want to take advantage of this method. To learn more, I suggest you read Open Space Technology: A User’s Guide by Harrison Owen. Incorporating Gamification


Gamification adapts game concepts to non-gaming situations in order to engage employees and motivate them to improve their performance and behavior. It rewards employees for completing performance levels with points, badges, privileges, and sometimes monetary incentives. While initially an extrinsic motivator, it is a way for the enterprise to reward those who embrace Agile and the focus on customer value.


The key to gamification is that it must be driven by a clear business objective. Within the context of Agile, the goal of gamification is to encourage employees to become Agile champions and achieve an Agile culture. Gamification can be deployed to engage employees in Agile educational elements.


Although it may start with training, you eventually would like employees acting as Agile champions to give back to their community. If you use gamification, ensure the achievement is real, it helps employees with their work, and is aligned with the objectives of the enterprise.


Supporting the Shift toward Agile Roles

Shift toward Agile Roles

In an Agile world, what used to be primary roles in a traditional workplace will shift when moving to an Agile workplace. An example is that Product Owners (PO) become the owners of value and decision making for their products.

There is less of a need for project managers and more of a need for the emerging roles of ScrumMasters, facilitators, and coaches.


Middle managers, who may have been the solicitors of the work, will find their roles change as the work is now coming from the backlogs via the PO.


Middle managers, who might be challenged by the new culture that Agile brings, are the same folks who traditionally conduct performance reviews. Because you are moving from a hierarchical world to a flatter world, this can be particularly disconcerting for some managers.


HR is well positioned to be the support for those whose roles are shifting. HR needs to understand the Agile roles well enough to explain the roles and offer support for those who change their roles.


Writing Goals in Canonical Form

Writing Goals in Canonical Form

There can be many ways to describe performance goals. It can be advantageous to draft them in as objective a manner as possible. HR may suggest the user story canonical form to specify the performance goal.


As a Scrum Team member, I will size the work using story points with the team during Sprint Planning, so that we gain team buy-in to support the velocity for the sprint and complexity of each story.


  • As a Scrum Master, I will exemplify servant leadership attributes so that I can help my team become self-organized.
  • As a Product Owner, I will continuously groom and prioritize the Product Backlog so that the Scrum Team has a list of user stories to work on.
  • As an Agile Coach, I will coach and mentor the product team so that they can adopt the Agile mindset.


Once you have the performance goal written in this form, you can decompose the goal-based user story to the tangible tasks. You may consider this as another interesting way to use the canonical form.


An alternate and promising approach to performance goals is Objectives and Key Results, also known as OKRs. The objective is the outcome that is sought, written in a qualitative, time-bound, and actionable manner. The key results are quantitative, written with three-to-five specific and measurable statements that help you know if you have met your objective.


OKRs should be cascaded from the enterprise to the division to the team and individual level, getting refined at each level to support the level above. In order to allow people to be innovative, it is recommended that only two-thirds of the OKRs be completed within a time period.


Moving to Team-Based Performance

Moving to Team-Based Performance

Because Agile focuses on the team, the performance goals and the evaluation should be a team -based. In traditional performance review models, upward of 100% of the goals are individual-based. Employees with individual goals conduct themselves toward the greatest potential for individual reward and security.


This is why individual goals are in polar opposition to the Agile team mindset. HR can help the enterprise move to team-based goals, which can only be accomplished by no longer incentivizing individuals to choose their success over team success.


It may be difficult to move to team-based objectives immediately for a number of reasons. The performance management system may not be functionally able to accommodate common goals across multiple people (the team), or you may want to maintain an individual-based component to the objectives, so the specific percentages across objectives may need to be applied.


You may want to take an incremental approach toward team-based performance. If you think to aim for 100% team-based objectives are too difficult, start with 50%. This will at least provide some incentive for individuals to work successfully as a team.


Gaining Insight into Employee Progress

 Employee Progress

When moving to the empowering environment that Agile brings to teams, the manager role will have less insight into what an employee is doing. The manager must learn that discussions of performance should occur in a continuous and collaborative manner, focusing on progress and learning.


The challenges are two fold

First, the employee is not taking work orders from the manager any longer; instead, the work should be driven from the backlog. Second, the manager actually does have less visibility into what the employee is doing since the employee is committed to the team. How does a manager gain first-hand information?


During the daily Scrum, the manager may quietly listen to the progress the team members share during this brief session. During the sprint review, the manager can quietly view employees’ progress by seeing what is being demonstrated.


The word quietly bears emphasis. Agile practices are not for the manager’s benefit, but rather for building customer value and making progress.


Hiring for Agile-Minded Employees

Hiring for Agile-Minded Employees

When hiring for Agile- minded employees, focus on how intrinsically motivated they are. While extrinsic motivators exist such as expecting to be well paid or paid equivalent to peers, once you move beyond the basics, you should look for employees who are intrinsically motivated by the work.


This may not be so easy. Some employees look at work as just a job. What I mean by this is that the intrinsic motivators of these employees are enjoying home life, hobbies, and their friends, and they have few intrinsic motivators at work. This is not a judgment but rather something to be aware of.


Other employees look at work as their career. While they may have intrinsic motivators at home, they have equal intrinsic motivators at work to improve their competency in their job. They take pride in producing a quality product, and they have a cause to make everyone on their team better.


If you are willing to build a culture where employees matter, having intrinsically motivated employees can help you achieve this. The question is, what does HR look for when hiring intrinsically motivated employees? Look for thoughts on autonomy, mastery, and purpose. Ask them the following questions:

  •  What things are you learning on your own?
  • What is the last article you read?
  • What are you curious about?
  • What are your goals in mastering skills?
  • What do you think about autonomy in your work?
  • What role does a customer play in building products?
  • What are some ways to promote collaboration?


In general, look for things where the interviewees can expand on what they value at work, which brings them meaning, how they describe progress at work, and what drives them to build mastery. 


Are You Adapting toward Excellence?

Agile world


Initiating an Open Space Unconference

They decided to use Open Space Technology in an attempt to identify the common Agile-related challenges in delivering customer value. There was a call-out to teams doing Agile to join. The facilitator opened up space by sharing guiding principles and logistics.

Initiating an Open Space Unconference

Participants posted their topics on the marketplace of ideas. There were enough ideas posted that three break-out timeframes where conducted. At the start of the first break out, participants self-organized around the topic that interested them. Participants could use the Law of Two Feet to move from topic to topic according to their level of interest.


At the end of the timeframe, the facilitator shared the “Evening News.” After three such rounds, the facilitator’s notes were gathered and the session was closed. The report summary was prepared.


Getting to Agile and Customer Value - Report Summary

  • Not everyone was participating in the Agile change particularly most of the management


  • The realization that an annual planning cycle left many great ideas in a holding pattern for upwards of a year (until the next planning cycle)


  • There were no measure of value and no effective means of prioritizing the work, so all were treated equally
  • Many of the ideas were built as big bang projects. While an iterative method was being applied, teams felt that they had to build it all


  • There were very few customer feedback loops and some of the ones they had, the feedback really wasn’t being incorporated very effectively
  •  Few really understood their customers well, who they were, what motivated them, and how they used the company’s products
  • While Product Owners were being deployed, most of the priority was still being driven by managers


  • A lot of focus on shortening the development cycle and very little on the end-to-end lead times
  • Reorganizing teams so often to move teams to the work resulted in teams constantly having to reform
  • Employees on teams felt that they had very little control over their work


There was too much certainty upfront on what customers wanted which was surprising since it didn’t feel like much was known about the customer. There was little Agile education to give people a common understanding of what Agile is (and isn’t)


Budgets and projects seemed to be set for the year so when higher value work came in, there was often no budget and team for it

  • With 100% utilization of people, there was no time to form bonds in an Agile community or for innovation.
  • Still being measured based on cost and schedule with no focus on value or flow of work
  • Very little connection between the company strategy and the work the teams were doing


This led to a fairly clear conclusion. If the enterprise wanted to gain the business benefits that Agile can bring, it must get serious about a cultural transformation toward Agile.


The good news is that there was a senior leader who wanted to become an Agile sponsor. The Agile sponsor allocated money to build a small team of Agile coaches.


She brought in one Agile consultant who had enterprise Agile experience and promoted three Agile champions from within the company who were willing to grow further. These coaches called themselves the Agile Advantage Team.


The Increments of an Agile journey

The Increments of an Agile journey

The two principles that drove the Agile Advantage Team were focused on being customer-value-driven and employee-focused. They used these principles as a litmus test for all of the adoption activities they considered. Did the activity move the needle toward customer value and empower employees?


Since the team was small, they took an incremental approach toward adopting Agile. This way, they learned from the results of each increment before they moved ahead, very similar to the Agile approach taken to incrementally build a product.


They used an adoption approach focusing on learning, growing, accelerating, transforming, and finally sustaining the Agile adoption.




“Learn” primarily focused on understanding the enterprise’s focus on value, learning about the people (that is, employees), and offering to learn. This started with a base-line to understand where the enterprise was from an Agile perspective.


It incorporated details from the Open Space report summary and was extended to include interviews from key leaders to gauge the enterprise’s focus on customer value and employee engagement.


Value-based questions focused on how value is measured today and how that value is validated along the way with customer feedback. It also included base-lining existing data such as how long it takes to deliver an idea from the moment it is recorded to when it is released.


To learn about the people, employee-based questions focused on levels of collaboration, ownership, motivation, enthusiasm, trust, and safety, with a particular focus on self-organizing teams.


As the coaches were learning about the enterprise, they were providing Agile education primarily focused on reading the minds of those who expressed an interest in Agile.


This involved an Agile 101 session of Agile values and principles, what a customer-value-driven enterprise looks like, and an understanding of what the current Agile galaxy looks like for their enterprise.


The results of this increment highlighted that there was little focus on customer value throughout the enterprise. There were a few spots where both Agile and self-organizing teams were understood. Also, lead times for delivering customer value were very long, averaging about 28 months.



Agile Advantage Team

The Agile Advantage Team coaches opted to work from a pull model where they would initially provide coaching to teams that were asking for Agile help.


They thought that the teams that were showing enthusiasm for Agile were more likely to put more effort into owning their Agile change. Coaching focused on helping teams begin experiments in bounded authority and self-organizing around the work.


The Agile Advantage Team coaches also began their own education program focused on helping the enterprise increase customer value through delivering early and often, optimizing the end-to-end flow for faster delivery, enhancing quality through fast feedback loops, increasing employee motivation and ownership, understanding coaching, and learning ways to promote change.


They did this in the form of an Agile coaching pathway of education where there were at least 18 Agile and Value, Flow, Quality (VFQ) topics covered over a period of similar weeks. It seemed like a long period, but learning is best achieved over time and enterprise transformation is serious business.


Following the pull model, the Agile Advantage Team coaches initiated periodic Agile meet-ups within the company.

All employees could join and it included a specific Agile topic for the first half and a Lean Coffee approach for the second half, where attendees decide the agenda. These helped coaches understand the topics of interest that fed into the Agile adoption effort.


The biggest focus in “Grow” was experimenting with an enterprise idea pipeline model. This involved establishing an enterprise portfolio of ideas and applying a cost of delay (CoD) to understand priority and order of magnitude differences among ideas.


This provided visibility to leadership on low-value work being done at the expense of high-value work waiting in the pipeline.


Education and experimentation with leadership and chief product owners occurred around a customer-value-driven model so it could be tailored to the specifics of this enterprise. This formed the beginning of a continuous Agile budgeting framework.


The depth of Agile Adoption

Depth of Agile Adoption

The pull signals led the Agile Advantage Team coaches to expand coaching with teams and leadership. 

They also experimented with a more formal education program that focused on employees and teams that wanted further education, again using a pull system. They did this in the form of an Agile practitioner pathway (APP) where there were at least eight topics covered over a period of similar weeks.


The topics included the discovery mindset, increasing customer value by delivering early and often, optimizing the end-to-end flow for faster delivery, and enhancing quality through fast feedback loops (for example, VFQ).


These pathways used work-based education where, after learning a topic, the cohorts applied the knowledge to their own teams for greater learning, which also advanced the adoption.


The coaches began experiments with story mapping for those engaged teams to improve decomposition and cut increments that bridged the gap between idea at the enterprise level and user stories at the team level. This helped employees better understand the requirements tree from strategy to ideas to increments to epics and user stories.


In addition, since the historical data highlighted that many high-value ideas would wait for long periods of time before they got worked on, a value stream mapping experiment was initiated on several product lines to understand the process efficiency. Efforts were then made to eliminate bottlenecks and reduce wait states.


It became evident that in order to align with customer value, customer feedback was needed along the way. A few of the teams wanted to experiment with customer feedback loops.


The coaches were happy to support this experiment in applying the customer feedback vision practice to better understand customer personas and where feedback loops may provide the highest-value feedback.


Since there was a decision to continue with the enterprise idea pipeline and cost of delay experiment for the next six months, it was felt that it was prudent to experiment with Agile budgeting to allow a more effective means of aligning to high-value ideas (that is, demand) and adapting supply to meet this demand.


Leadership and finance became part of the group that learned and began experimenting with this concept.




Feedback from “Accelerate” was positive so the enterprise committed to “Transform.” This focused on three increments. The first focused on role evolution, scaling coaching, and education for product owners who lead with value, HR engagement, and commitment to Agile across the enterprise.


The second focused on leadership education, dependencies across the work, and measures of success. The third focused on scaling education, influencing outside vendors to apply Agile and assessing our state of Agile.


Transform One

The first increment of “Transform” started with many teams committing to Agile (bottom-up) and leadership committing to Agile (top-down). This provided a good overall balance of commitment although it was also stated that no one would be forced to become Agile.


Now that there were many people keen on applying Agile, there was a need to scale the coaching. The Agile sponsor agreed to add four more coaches to the Agile Advantage Team.


The coaching positions were filled with two external hires and two internal Agile champions. They were educated in a pattern similar to the Agile coaching pathway.


Education was focused on those that had the responsibility of driving customer value, which included product owners and product managers. The product owner pathway focused strongly on understanding the customer with personas, identifying value with the cost of delay, challenging assumptions, and establishing customer feedback loops.


Also included was a focus on role evolution as the coaches, management, and teams realized that some roles were already changing (for example, needing product owners, moving from project managers to ScrumMasters, and evolving management’s role). HR realized that it had a role to play in role evolution and the Agile adoption effort in general.


HR took part in understanding the elements of embracing employees focused on building trust, learning more about intrinsic motivation, promoting collaboration, and so on.


HR also started to realize the importance of building a learning enterprise so it started taking part in understanding the discovery mindset and participating in experiments.


Transform Two

education for leaders

The second increment of “Transform” focused on education for leaders (executives and middle managers), a particular focus on dependency management across teams and ideas, and establishing and operating with success measures.


Education for executives and managers focused on a combination of understanding their role in an Agile enterprise, how to support the use of an enterprise idea pipeline, and how to engage with their teams using the language of customer value and capturing feedback.


As the enterprise idea pipeline was used, it became evident as early as the Record through Refine stages that some of the ideas required effort from multiple teams.


This led to promoting lightning-bolt-shaped teams so that a team could work in more than one area. It also led to restructuring some teams to include a more cross-functional set of skills that reduced dependencies on other teams.


This started with experiments in both areas with executives and managers adapting as they learned what worked better to reduce cross-team dependencies.


As management played a role in optimizing flow by removing impediments, there was a particular focus on the time it took for an idea to go from the Record stage to the Release stage (that is, lead times).


In addition, there was a focus on looking for ways to reduce approvals, hand-offs, waiting, and so on. This also included a strong focus by product owners and teams on decomposition and cutting increments of value from the idea.


Finally, there was a spirited discussion focused on measures of success for getting to customer value. Initial discussions focused on the importance of measuring outcomes over output. This continued with a discussion of having leading indicators since outcomes are lagging measures.


Primary measures for getting to customer value included value curves, driving with CoD, customers at demos, customer satisfaction, tracking end-to-end lead times, and customer revenue (the outcome measure).


Employee satisfaction was also included. An enterprise dashboard was established as a means to correlate and understand progress, to avoid sub-optimization of over measuring, and to improve decision making.


Transform Three

Agile culture

The third increment of “Transform” focused on scaling education, establishing an assessment that focused on an Agile culture, and influencing outside organizations to align with Agile.


Now that there were many people keen on applying Agile, there was a need to scale the delivery of education. Since there were a number of local Agile champions within the company, they were leveraged to help co-deliver the Agile practitioner pathway.


Most were very enthusiastic as it was their way of giving back to the Agile community. A large number of employees were educated in a relatively short period of time.


As the transformation continued, there was a focus on assessing the Agile culture to gain an understanding of the Agile adoption was leading to a transformation. The Agile Cultural Assessment Survey was used to gauge the current level of the Agile mindset in the enterprise.


This was combined with the success measures on the enterprise dashboard to correlate Agile cultural alignment with a customer focus. Due to the focus on removing impediments and cutting increments of value, lead times were reduced from the original 28 months down to three months.


It was learned that some of the impediments that were slowing the enterprise were the way outside companies delivered to OnHigh.


Often, when something was provided, it would have to be reworked in order to integrate the amount of feedback that was gathered. This led to educating vendors on the Agile mindset and the incremental cadence expected in their work.


It also included experimenting with how to work with vendors in less of a time-and-materials approach and more of an inspect-and-adapt and incremental approach. This helped to further reduce the end-to-end lead times.




Transitioning to “Sustain” doesn’t mean you are done focusing on Agile. However, the culture was focused on identifying, validating, and delivering customer value and on teams self-organizing around the work. “Sustain” effectively lasts indefinitely, with peaks and troughs of effort depending on the shifting needs of the enterprise and leadership changes.


As leadership and employees change, there is a continued focus on education and coaching. While levels of coaching support are often less than previous increments, a continued focus on Agile concepts, practices, and mindset remain in place.


After a few tweaks to the Agile Cultural Assessment Survey previously mentioned, it was decided that it would be used during the “Sustain” period at least for the next year.


There was also a focus on honing existing concepts and practices as feedback was received on what worked better. This included introducing new concepts and practices focused on bringing higher value to the customer.


It should be noted that each increment of the Agile adoption that led to an Agile transformation took about six months. Added up, this was more than three years. Transforming an enterprise takes time since it involves a mindset shift and new ways of working. Don’t underestimate the effort.


Focusing on Customer Value

Focusing on Customer Value

When an organization works on too many ideas at once, the overhead and context switching slow teams down. The more things you start, the fewer things you finish.


Even when you limit the work in progress (WIP) to the capacity of the development teams, you often overload related organizations—manufacturing, sales and marketing, training, or customer support. 


When organizations ignore customer value, the portfolio of work can get filled with low-value items. Capacity limits force companies to ignore better opportunities.


To maximize business outcomes, you need an objective way of selecting the programs that will deliver the highest customer value. Record stage was referenced in the enterprise idea pipeline.


In Record, a value is used to rank order ideas to help the enterprise focus on the highest-value work. Prioritization methods help you come up with an optimal rank order. The best ones will provide an objective value or score.


Highlighting Prioritization Methods

Highlighting Prioritization Methods

At the sprint level, it is the right and responsibility of the product owner (PO) to have the unilateral responsibility of priorities in the product backlog. Good POs regularly meet with their stakeholders (customers, chief product owners, sales managers, architects, technical managers, and so on) to get input for prioritization.


Some POs add structure to the process using one or more of the following prioritization methods:


Moscow: This method helps frame the PO’s thinking to define the smallest possible solution that could possibly work.


This approach places a level of importance on each requirement including a wish-list container that helps bucket features or stories that should be recognized as having been considered and explicitly deferred or rejected. This approach succinctly explains the decisions that have been made and allows the team to focus on the “must haves.”


Buy a Feature: This is an online “game” developed by Innovation Games (now Conteneo) to help POs choose the features to include in an upcoming release that would be most valuable to their customers or stakeholders.


Each feature being considered is listed along with a “price.” The price might be related to the estimated development cost or anticipated customer value.


The players (customers) are each given a fixed amount of play money to spend on features. Expensive features may require customers to negotiate and pool their money. This is encouraged. Playing this game multiple times with different sets of customers can give the PO useful data on what is more likely to satisfy customers.


HiPPO: Senior leaders typically have many years of experience in the industry. Even when they want their teams to own decisions, they feel that it’s their duty to share their knowledge and offer opinions, particularly on priorities.


If they are expressing an opinion, treat it as one of many inputs from the stakeholders. If they believe their opinion is the correct one, you might have to accept their opinion as for the decision. This is known as HiPPO.


These are all qualitative prioritization methods. They are based on opinions and individual preferences. While qualitative methods are sufficient for product backlog and sprint-level planning, enterprise-level prioritization deserves economic justification. At this level, the stakes are too high to leave prioritization to subjective methods.


When you have many good ideas, you need an economic rationale to help sort the high-value ideas from the lower-value ones that clutter your portfolio and distract people and investments.


Many organizations make portfolio-level decisions based on HiPPO. There are rare instances where companies have completely disrupted industries and dominated their markets by implementing the vision of a single leader.


There are very few visionaries like Steve Jobs who can provide that kind of vision. Even Steve Jobs could be wrong. Remember the Newton?


Some of the common economically based prioritization methods include Return on Investment (ROI) and Weighted Shortest Job First (WSJF). ROI is (Value/Effort)*Confidence, where the value is typically measured in incremental revenue.


WSJF is a ranking based on subjective, linear, and relative business value. It factors in a relative-time criticality and risk reduction.


Since all three of these factors are estimated on a linear scale of 1–10, any one of these factors can be overweighted and distort this subjective view of the cost of delay. While these have been used in traditional organizations, they overlook some important elements that Agile enterprises need to consider.


Exploring Cost of Delay (CoD)

 Cost of Delay (CoD)

Since the goal of most companies is to make profits, it is important to understand the economic consequences of prioritization trade-offs. The best way to measure the value generated by an idea is the life-cycle profit impact, which is the incremental gross margin generated by that product over its useful life cycle.


CoD measures the life-cycle profit impact over time and, therefore, is an excellent way to clarify both the value and urgency for new ideas in the pipeline.


It is an economic-based method that allows companies to prioritize those ideas that will create the highest value by putting a price tag on time. As Don Reinertsen has said, “If you only quantify one thing, quantify the cost of delay.”


CoD is the net change in forecasted gross margin per week. CoD is typically stated per week to support the granularity of the impact of priority trade-offs. If you have an annual forecast, divide by 52.


By focusing on life-cycle profits, CoD makes it clear that prioritization decisions can be based on more than incremental revenue. Revenue is important, but it is only one of the four major ways in which an idea can impact profits. The contributors to life-cycle profitability are as follows:


1\.\ Increase revenue - Grow sales to new or existing customers with ideas that delight customers and increase market share. Disruptors increase market size and make the pie bigger.


2\.\ Protect revenue - When competitors or market conditions threaten the revenue stream. Ideas or innovations that improve current products can sustain current market share and revenue.


3\.\Reduce costs - Look for ways to increase efficiency that will reduce costs that are currently being incurred. This will improve the gross margin or profit contribution.


4\.\Avoid costs - Make improvements to keep the current costs constant. This eliminates costs that are not currently being incurred but maybe in the future. An example is conforming to new regulations to avoid fines.


Calculating Cost of Delay

Calculating Cost of Delay

A simple way to calculate the CoD is to determine the profit via all four contributors to profitability in a given year. It can also be done for a three-year period and then divided by three.


This CoD example will use a weekly figure to drive home the impact of priority trade-offs, so you divide the annual gain by 52. Here is the working calculation with examples:


CoD = (Contributors to Profitability including Increase Revenue + Protect Revenue + Decrease Costs + Avoid Costs)/52


Example #1: Increasing conversion rate. You have an idea in the pipeline that would improve the customer experience on your website, projected to increase the conversion rate from 5.5% to 6.0% (or a 0.5% increase).


If you have approximately ten million visits to your site per year, your average sales order is $32, and your average gross margin is 30%. The increased contribution to profitability from the additional revenue in one year is (10,000,000*$32*0.005*.30) or $480,000. The weekly CoD is $480,000/52 or $9,230. This is an example of CoD to increase revenue.


Example #2: New regulations. The Consumer Protection Agency has issued a new regulation requiring increases in information security to counter the latest threats from hackers.


The company ignored this regulation when it was issued. Now the security measures must be in place or the company will face fines of $100,000 per calendar day. Since we know the cost per day, the weekly CoD is $700,000. This is an example of CoD to avoid costs.


Example #3: New mobile application. Customers have been asking for a mobile app to access financial products. Having this application available could retain about 240,000 current customers and add another 360,000 new customers in the next year.


It is estimated that the company can make $36,000,000 in a year. The weekly CoD is $36,000,000/52 or $692,308. This is an example of CoD to protect revenue and increase revenue.


As a word of caution, do not use the CoD as a forecast. It is only a prioritization tool. When the CoD is used as a forecast, it becomes the target on the back of the product owner. This can drive fear into the organization and impact the value of the CoD.


As we will see later, assumptions can greatly impact the CoD. By challenging assumptions and applying a uniform set of standards about assumptions, the CoD of different opportunities can be compared. Therefore, protect the value of assumptions driving these important conversations and prioritization.


Incorporating Customer Feedback

Incorporating Customer Feedback

Customer Feedback Loops

Feedback loops are specific points along the idea pipeline where the output received from one activity is used as input in the next activity. In the case of building an idea, feedback from a customer who has attended a demo is used as input in the next planning session to adopt the direction for the product or idea.


Feedback is the result of an activity and can be termed as testing an idea. There are two primary types of testing: verification and validation. Verification testing provides you feedback to help determine whether you are building the product right and that it works as designed.


If the button is supposed to take you to a new location, verification testing will check it and provide feedback on whether it does or not. The testers in most verification testing are employees internal to the company.


Validation testing provides you feedback to determine if you are building the right product and are satisfying the needs of the customer. If the user story says to build a button, then validation testing would ask the customers if they are satisfied with the button, providing the enterprise with customer feedback to understand if the product is adequate or if a change is needed.


In this case, the testers in validation testing are meant to be customers who are external to the company. Customer feedback loops are, therefore, a type of validation test to ensure you are meeting the needs of customers.


Types of Customer Feedback Loops

Types of Customer Feedback Loops


Requirements Tree

I often recommend that a company or product team understand their requirements lineage, which I term a requirements tree. It is a structure that represents the relative hierarchy among various requirements elements within your enterprise. User stories are found at the smaller end of the requirements element spectrum.


Since requirements drive the work within an enterprise, it is good to know if you are working on the highest-value requirements or random requirements that made their way in through the secret and often unevaluated backdoor. Can you trace the lineage of user stories and tasks to the high-value idea they represent?


What are the various requirements elements? There is no industry standard group of requirements elements, and they can vary from enterprise to enterprise.


Attributes of Requirements Elements

Having a requirements tree benefits you in several ways. First, the tree helps you understand the relationships of the various requirements elements from the largest requirement (corporate strategy) to the smallest requirement (task).


Second, the tree helps managers and employees understand what level of requirement is being discussed. Third, it helps you understand if you are missing a requirements level. While it can be reasonable to miss a level, you should be aware of it to determine if a discussion is necessary.


As you think about the ideas that flow through your organization and how to decompose them into user stories and tasks, it is important to know what your requirements tree might look like and the attributes the requirements elements should have. This may include the following:


  • All requirements elements should be customer-value focused.
  • Other than corporate strategy, all other requirements elements should have a parent (the epic is the parent of the user story) unless unneeded (some user stories won’t have tasks).
  •  For every parent, there are typically two or more children requirements elements (an idea is made up of six epics).
  • Not all children need to be completed in order for the parent requirements element to satisfy the customer need (five of the eight user stories of the epic may satisfy the customer).


Within an enterprise, different divisions, groups, and teams can have different requirements trees. The exception is that the more dependencies and collaboration among teams, groups, and divisions, the more mutually beneficial it is to have a shared and common requirements tree.