Agile User Story (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). User stories are the primary topic discussed in grooming and sprint planning.


The intent of a user story isn’t to specify every detail of the need but to provide enough business and technical detail to have a healthy and collaborative conversation about the story.


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.


Acceptance Criteria for an Agile User Story

Acceptance Criteria for an Agile User Story

The acceptance criteria are an important attribute of a user story. Each user story should have its own unique set of acceptance criteria. Acceptance criteria answer the question, “How will I know when I’m done with the story?” They do this by providing functional and nonfunctional information that helps set boundaries for the work and establishes pass/fail criteria for testers to establish the test cases that are used to test a user story.


Ideally, customers provide these criteria when they articulate the user story, but the PO usually writes the criteria, acting as the voice of the customer. If the PO is having problems writing acceptance criteria, team up with QA testers who can draw from their experience to help the PO.


To write effective acceptance criteria, state the intention, not the solution. In other words, state the “what,” not the “how.” For example, it is better to write “The user can choose an account.” rather than “The user can select the account from a drop-down menu.” The acceptance criteria are independent of implementation details.


If the user story is “As Erin the Senior Citizen, I want to create an account so that I can become a member of the site,” then the acceptance criteria for a user story may include the following:

  • The user is presented with an account creation option.
  • The user must enter an e-mail address and a password.
  • The password must follow the security policy.
  • Provide user account confirmation within five seconds.
  •  User lands on the home page after creating the account.


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.


Do User Stories Promote Conversation?

Do User Stories Promote Conversation

To get to a user story, the journey occurs both before the user story takes shape and after it is written, and it should be collaborative and evolutionary. The written user story is a promise for a conversation that helps the team both understand and shape the outcome to better meet customer value. Ensure you promote the conversation with the team and others.


User stories form the backbone of the work on your team. As you write user stories, consider a requirements language construct such as the canonical form. Including the persona or whom the functionality should be built for help, you understand the point of view of the persona. Including the action helps you understand what needs to be built.


The business benefit helps you understand why the functionality is needed. These elements provide clarity for the team to build what the customer wants. The collaborative approach ensures that everyone on the team understands the customer needs so they can better build something the customer wants.


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 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.


Working with the Backlog

Working with the Backlog

A backlog is effectively a list of prioritized work. Teams in Agile operate from a backlog typically called a product backlog but may be referred to by other terms. Backlogs can be stand-alone, although I recommend that they are connected to the enterprise idea pipeline of work on the higher end and even a maintenance backlog of work on the lower end.


Product Owners own a backlog. It is their primary tool for collecting and managing requirements. It should be the single source of requirements for both transparency and efficiency reasons. The PO typically adds work items to the backlog and prioritizes them according to the value-based prioritization method he or she chooses to use.


The team should have continuous access to the backlog. In the spirit of self-organizing, anyone may contribute work in the form of epics, user stories, and tasks to the backlog. However, only the PO can prioritize the work. The team should have edit rights to add details to each work element whether epic, user story or task.


When you look at a backlog, what do you see and how deep do you look? If a backlog is prioritized, you see the requirements elements that are deemed the most important at the top.


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.


The sprint backlog is a backlog of work that fits into a sprint. It represents a subset of user stories that are prioritized high enough to get pulled into the sprint. Those stories that are the highest priority and fit the team velocity or amount of work a team can complete within a sprint become the sprint backlog.


There is a unique sprint backlog for each sprint. The items in the sprint backlog get pulled from the product backlog during sprint planning. The sprint backlog forms the backbone of the work within a sprint.


The team backlog is a backlog of work that is meant for a team. It is beneficial when you have multiple Scrum teams building a product together or if the team is non-product specific.

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 a 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 a 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 (or a defined 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 (T-shirt sizing of S/M/L or even story points). 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 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

In an Agile world, writing down requirements provides a focal point where you can have collaborative conversations between the business and engineering sides. Whether this is between the PO and team or the customer and tester, the importance is that a shared understanding begins and continues.


This discussion initiates the learning between the business and engineering sides where the engineering side better understands the customer value of the requirement and the business side better understands the options that can suit the customer needs.


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 of 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

User stories are a form of requirements. The challenge with the word requirements is that it may indicate requirements at many levels and sizes, such as user requirements, technical requirements, and business objectives. Because of the possibility for confusion, You need to determine where any particular requirement belongs by virtue of its scope


A more detailed definition of 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 user story is the equivalent of a business or user requirement and is collected and managed by the PO. Stories provide user functionality that represents value to the customer. It should be non-compound and have one persona. A user story should be able to be built within a sprint. The next section discusses user stories at length.


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 a 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

Promoting Agile Budgeting

What makes up customer value is changing at a faster and faster pace. Many market leaders have found themselves lagging behind new leaders. Market share from a decade ago may have disappeared and been taken over by new competitors. As markets change and new customer needs emerge, do you have the ability to adapt?


Can you adapt your budgeting to the market demand, making people and resources available to capture market share or prevent a reduction in your market share?


It is important to have a budgeting framework that can handle the shifts in the market, turning quickly to the new direction. This takes a combination of looking at your current supply-and-demand system and having the ability to adapt.


You also need a budgeting framework that reduces wait states and ensures that the highest-value ideas get to market quickly. While this isn’t easy, not doing so will only make your current position in the marketplace more challenging.


Moving Away from Traditional 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.


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 the 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 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 an 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 a 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 worked 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.


Applying Agile Success Measures

Agile Success Measures

This blog is not intended to be an inclusive set of Agile measures. It is meant to provide you with enough information to get started in building your measurement framework and use it to determine if you are successfully delivering customer value. Focusing on customer value means that you need metrics that help you gauge if you are moving in the direction of customer value.


Outcomes Matter

The primary goal of Agile measures is to help you become more aligned with delivering customer value. This is why outcome-based measures are much more aligned with Agile than output measures. Output measures focus on how much you delivered, while outcome measures focus on the results of what you deliver. It is the results that matter.


Outcome-based measures are drivers to help you understand business success. You may still need output measures to help you on your way; just ensure that they are relevant to help you determine if you are reaching the outcomes you are looking for.


An outcome focus changes your perspective from an internal one to a customer or external perspective. This allows you to better understand what you are aiming for in the customer-value-driven world you need to establish.


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 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 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 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.


Reinventing HR for Agile

Reinventing HR for Agile

“Employees matter” is a key principle in Agile, and Human Resources (HR) is there to support employees and build an environment that helps them stay motivated, productive, and thrive. There are opportunities in the HR environment to become more value -added to employees. 


HR teams are poised, should they be willing, to take a leadership role in Agile and move to the next generation of a supportive environment for employees. this can include promoting Agile and the discovery mindset, experimenting with motivation, exploring self-management, fostering servant leadership, getting closer to the customer, facilitating Open Space, incorporating gamification, supporting the shift toward Agile roles, moving to team-based performance, moving toward continuous employee feedback, and hiring Agile-minded employees.


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 the 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.


Promoting the Agile and Discovery Mindset

Agile and Discovery Mindset

HR can promote new programs within an Agile framework and mindset. By applying the discovery mindset including incremental thinking, experimental thinking, divergent and convergent thinking, feedback thinking, and design thinking,


HR can promote the education surrounding the elements of an Agile and discovery mindset. This education can be brought in as one of the early orientation programs as new employees are brought in. HR can team up with Agile coaches to determine the right level of education and how Agile knowledge can be periodically built over time via education and experience.


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?


Exploring Self-Management

Exploring Self-Management

Self-management is a relatively new concept and effectively asks you to think of operating without management. It asks you to take the bounded authority to the level where those who have the most information make all of the decisions for a particular space.


The more predominant alternative to self-management is the traditional management structure where top-down hierarchical decision making occurs. Within a self- managed an enterprise, there are few management levels and employees are happy, as they are both self-directed and empowered to make decisions.


Self- management also leads to optimizing the flow of delivery and improvements as the bureaucracy of a traditional management structure is effectively eliminated because waiting for top-down decisions from people who have less knowledge no longer occurs.


Since self-management has a very real and direct impact on how an enterprise operates, it should be an area where HR can have a strong role. This starts with HR’s learning how self-management works. HR can set the tone for experimenting with self-management.


It can explore self-management within its own HR group and then help management and teams expand boundaries and remove the system impediments from achieving self-management. A good resource for self-management is the Morningstar Self-Management Institute.


Fostering Servant Leadership

Fostering Servant Leadership

Providing management with a servant leadership mindset can result in stronger relationships between leaders and their teams and direct reports, which can lead to higher degrees of loyalty and productivity. Servant leadership focuses on servicing your employees first. Instead of being in front and giving directives to your team, you are leading from behind, sharing ownership of what needs to be done with integrity.


In their blog Servant Leadership, Robert K. Greenleaf and Larry C. Spears share ten attributes of servant leadership: listening, empathy, healing, awareness, persuasion, conceptualization, foresight, stewardship, commitment to grow people, and building community. This forms the basis for education that can be given to an enterprise’s leaders.


In his blog Turn Your Ship Around, L. David Marquet emphasizes that true leadership is about giving control instead of taking control. This helps improve morale and performance, and it reduces retention. The information in this blog can be used as an example of true servant leadership.


By learning and experimenting with servant leadership, HR will be poised to embrace and promote servant leadership within its enterprise. HR should also attempt to identify the servant leaders since those that exhibit servant leadership often go unrecognized and avoid the limelight by choosing to put the light on their team members. To gauge if you are a servant leader, ask yourself, “Am I serving others or myself first?”


Getting Closer to the Customer

Getting Closer to the Customer

As part of the shift toward customer value, HR can promote the two-degrees-of-customer-separation technique that emphasizes the relationship between the customer and company employees. The goal is for HR to have witnessed the products the teams are building and meet the customers those products are meant for by attending demos or sprint reviews and visiting customers who are using products from the company.


The benefit of HR’s having a customer view can help in two ways. First, HR has the first-hand experience in how teams are working with customers and gaining customer insight.


Second, HR can use this experience to better understand the needs of the employees in the company. HR can then better promote how you lead by learning what a customer wants using discovery, experimentation, increments, and feedback while avoiding certainty in thinking that you know what a customer wants.


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 a 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 aiming 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.


Moving from Annual Performance Reviews

Moving from Annual Performance Reviews

Some companies are moving away from the annual performance review approach and instead applying more frequent conversations. They are also moving away from forced rankings as this supports an individual-based performance system. The challenge with an annual cycle is that it rewards and punishes employees based on past performance with less focus on newer improvement and growth.


HR can help an enterprise move away from traditional annual or biannual­ performance­ reviews. A good first step is to transform your performance reviews into a weekly or bi-weekly discussion between manager and ­employees with a more continuous and collaborative approach in discussing objectives, challenges, progress, and learning.


The goal behind this is that employees should never be surprised by a performance review because there should be continuous feedback from their manager.


These sessions should be low-key and replace the “big-bang” performance reviews. There should be an effort from both management and employees to be transparent to avoid surprises when ratings or compensation matters are discussed. Ultimately, the performance review process should move away from the stodgy, often negative and intrusive event and evolve into a continuous and collaborative discussion on progress and employee needs.


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, what brings them meaning, how they describe progress at work, and what drives them to build mastery. 


Are You Adapting toward Excellence?

Agile world

HR is poised to play a whole new role in an Agile world and in enterprises focused on delivering customer value. The annual review of traditional performance management is out of touch with today’s ever-changing employee needs. “Employees matter” is a key principle in Agile, and HR can support employees and build the next-generation HR environment that adapts to employee needs.


Through a combination of promoting Agile and the discovery mindset, experimenting with ways to motivate employees and self-management, fostering servant leadership, getting closer to the customer, facilitating Open Space, incorporating gamification, supporting the shift toward Agile roles, moving to team-based performance, moving away from annual performance reviews to continuous feedback, and hiring for Agile -minded employees, HR can help employees stay motivated, productive, and thrive.


The question is how will you adapt your enterprise toward the next generation of performance excellence and human resources?


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. As illustrated in Figure, 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.


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 the 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.


How Will You Write Your Agile Story?

How Will You Write Your Agile Story

Now it is time for you to write your Agile story. Is your Agile galaxy comprised of a holistic top-to-bottom and end-to-end view of Agile where everyone is engaged? Are you a customer-value-driven enterprise that emphasizes learning customer value through customer feedback? Are your employee's given ownership and do they feel like they really matter?


Imagine that your enterprise focuses on the highest-customer-value work. A place where all of the ideas from strategy down to tasks are transparent and visible so everyone knows if their work is aligned with strategy and high-priority ideas. Where employees use 100% of their brain power to self-organize around the work and be trusted to build customer value.


Where a discovery mindset wins over certainty thinking. Where managers are leaders, leading people with inspiration, vision, and trust. Where customers embrace the products and services being built because they are engaged in the building of the work all along the way. Imagine!


Now it is time for you to imagine your future. Hopefully, this blog has provided you with many cutting-edge Agile concepts, mindsets, practices, and techniques to help you adopt Agile throughout your enterprise. It is time for you to write your Agile story. I hope it is one that captures your journey from idea to delivery and from the team level to the executive level. I wish you the best as you imagine and implement your Agile story.


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

When working with teams and projects, you may have used some of the simpler, qualitative methods for prioritizing the product backlog. Some teams just follow the product owner’s (hopefully well-informed) opinion. Some other methods include Moscow (Must Have, Should Have, Could Have, Won’t Have), “Buy a Feature,” or HiPPO (Highest Paid Person’s Opinion).


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

The most important ingredient in understanding customer value is precious customer feedback. A customer-value-driven (CVD) enterprise is a company that optimizes for what the customer finds as valuable and adapts until this outcome is met.


As a reminder, who is a customer? A customer is someone who has a choice of what to buy and a choice of where to buy it. A customer is someone external to the company and pays money to help you stay in business by purchasing your product. Consequently, engaging the customer is of utmost importance.


When talking about customer feedback in this blog, we are referring to people who are outside of the company who have the choice of buying your product and, hence, providing revenue to the company.


Throughout this blog, I will discuss incorporating feedback loops along your delivery axis, constructing personas, embedding personas, and creating a customer feedback vision. By doing these things, you can more systematically understand your customers and engage them during many meaningful moments to receive their precious 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.


The mindset behind Customer Feedback Loops

The concept of learning what the customer considers valuable is an important mindset in the journey to customer value. This learning allows you to shed the dangerous attitude of pretend or arrogant certainty and allows you to explore what the customer needs. The best approach is to incorporate the concept of learning through feedback to identify what is customer value.


This is a discovery method of gaining incremental information through customer feedback loops and taking what you learn to continuously adapt toward customer value.


The goal is to have as many customer feedback loops as feasible. This can be challenging and, in some Agile efforts, the result is few if any customer feedback loops. Customer feedback can be an uncomfortable endeavor in that it can frustrate those who’ve invested time into a building a product. It requires a mature and willing mindset to collect, consider, sort, merge, and apply the feedback to get closer to customer value.


To prevent frustration and pride of ownership when a lot of time has been invested in working on a product, apply short iterations or periodic time-frames where demonstrations occur more regularly. This limits the investment of time before it gets reviewed and ensures you don’t move too far in the wrong direction before customer feedback is gained.


As simple as it sounds, embrace the fact that customer feedback is a very positive outcome, ensuring the betterment of the product and company success. If you are used to a process where you sub-optimize for following a plan over responding to customer change, then responding to change by accepting customer feedback can be a tough mental shift. The answer is to develop a discovery mindset that is always willing to collect customer feedback.


Also, spend time identifying the best feedback loops for the effort and construct a sound vision for customer feedback. As you consider the best customer feedback loops for your effort, look for places along the delivery axis where getting feedback is of high importance and low effort. A good example is the Web-based sprint review or demo. Customers can observe the demo in a low-effort manner from the privacy of their office or home.


Types of Customer Feedback Loops

Types of Customer Feedback Loops

There are many types of customer feedback loops that can be applied as the idea travels through the enterprise idea pipeline. The most common customer feedback loop is the sprint review or demo where customers view the working product developed to date.  there is a list of customer feedback loops with details that you should consider applying to build a stronger path toward customer value.


Stages in Customer Feedback Loops

  • During the Reveal stage, share the idea on a Lean Canvas or Customer Value Canvas with customers. Then walk through the idea with customers to see if the idea’s manifestation is what they had in mind or if it is something that they would find valuable. The goal is to understand if you are moving in the direction of customer value.


  • During the Refine stage, bring in customers to review the user story map prior to cutting an increment. Highlight the backbone and process in order to validate the customers’ experience path. Then walk through the options to gauge their level of interest and to see if some options are more compelling than others. The goal is to move in the direction of customer value.


  • During the Realize stageinvite customers to the sprint review or demo. This is a type of feedback where the team or PO demonstrates the working product completed during the sprint to customers in order to highlight progress and gain the all-important customer feedback. The goal is to have demos periodically so adaptions to customer value can occur regularly. The goal is to move in the direction of customer value.


  • During the Realize stage, invite customers to participate in a hands-on customer-experience activity. This is a type of activity where customers experiment with the product in a hands-on manner in a simulation or pilot environment. Such activities may be a form of a customer or user experience exercise and may be known as alpha or beta. The goal is to gain usability and satisfaction feedback.


  • During the Release stage, for those on-premise products that require installation, ask customers for product-installation feedback. This is a type of validation where customers physically install the working software in their environment. This can apply to customers installing a product onto servers or mobile customers downloading an app. In both cases, receiving technical and satisfaction feedback is beneficial.


  • During the Reflect stage, the idea has made its way to the public. This is a time to collect an array of feedback: how well it is doing in the market, how many customers have paid for the product, if the deliverable is satisfactory to customers if the product is being used as advertised, and more. Primarily, the goal is to capture revenue data, market share data, and customer satisfaction data to ascertain if it is perceived as valuable to customers.


  • As you look at possible feedback loops, the question is not about having a lot. The question is about having feedback loops at points where they can help you understand customer value. Some feedback loops may return less feedback value than the effort it takes to establish them. Look for the “high feedback value, low effort to establish” feedback loops first.


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.