Tag Archives: enterprise agility

Agile Metrics: Output Vs Outcome

Posted on by

Before we dive into Output Vs Outcome-Based Agile Metrics, let us understand what is meant by output-based and outcome-based metrics. Output-Based metrics measure the amount of work completed whereas Outcome-Based metrics measure the value delivered by the completed work.

Output-Based Agile Metrics

Metrics that measure how much work was completed in a given duration are said to be output-based. For example, the number of user stories completed in a Program Increment (PI) or an iteration measures the number of tickets completed in a specified duration. Other examples are:

  • Number of features completed in a Program Increment
  • Number of story points completed in a Program Increment
  • Number of story points completed in a sprint or an iteration

Such metrics can be easily gamed and do not provide any value-add. For example, Team A delivers 6 user stories whereas Team B delivers 12 user stories. This metric does not signify that Team B has better productivity than Team A.

Let’s assume Team A delivers 40 story points and Team B delivers 20 story points. Do you think Team A is a better performing team than Team B? Well, a team’s velocity does not provide insight into a team’s performance. Team A might have inflated their story point estimates or they might be working on user stories that do not deliver a potentially shippable product increment or bring any business value. 

Measuring the amount of work done is an Agile anti-pattern and should be avoided. It does not provide any value and may encourage Agile anti-patterns such that teams write tasks as user stories, create unnecessary user stories that do not bring any business value, and inflate story point estimates.

Outcome-Based Agile Metrics

Metrics that measure the outcome or the end-value delivered by the completed work are said to be outcome-based. For example, the business value delivered is an outcome-based metric that measures the amount of business value delivered by a unit of work during a specific duration. Let’s discuss how to measure the business value for an EPIC, Feature, or User Story. 

How to Measure the Business Value

Measure the delivered business value at an EPIC or a Feature level, rather than at a User Story level. Think in terms of:

  • Will this EPIC or Feature enable you to sell more units?
  • Will this EPIC or Feature allow you or your organization to make more profit?
  • Will this EPIC or Feature enable reduced operating costs for your business?
  • Will this EPIC or Feature enable a new capability for your end-users?
  • Will this EPIC or Feature reduce the manual effort for your team or end-users?
  • Does this EPIC or Feature enable your organization to compete in the market?
  • Does this EPIC or Feature allow to refine hypotheses about the market? 
  • Is this EPIC or Feature required to stay compliant with regulations?

Many EPICs or Features provide little to no value or aren’t actually desired by end-users. It’s important to prioritize the work effectively to deliver more business value. There are many ways to measure the business value like comparing the cost of delay, calculating Return On Investment (ROI), calculating revenues and expenses each month (Cash-Flow analysis), calculating Net Present Value (NPV), Planning Poker, and more. I suggest working with your business sponsors and:

  • Find Key Value Indicators (KVIs) for your product that you can measure at each Product Increment (PI) boundary.
  • Think about both qualitative and quantitative value indicators.
  • Review your KVIs regularly and revise as needed.

One of the simpler methods is to leverage the Planning Poker game and relatively estimate the business value for an EPIC or a Feature with your product stakeholders.

If you are interested to learn about other Outcome-Based Agile Metrics, enroll in my Udemy Course, Agile Metrics: Elevate Team Agility with Scrum Reporting.

You may be interested in my published courses and books as outlined below: 

Also, check out these articles…

The Future Of Agile

Posted on by

The Future Of Agile

What's the future of Agile? This article will discuss the current and future trends for the Agile methodology.

 

Where Are We Today?

Agile was formulated in 2001 with a Manifesto for Agile Software Development. Since then, several enterprises across the world have adopted the agile methodology. Most organizations build complex products using Agile frameworks such as Scrum, Extreme Programming, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), or Crystal. Several organizations leverage the Lean methodology alongside the Agile methodology and track their work using the popular Kanban method. Since these frameworks didn't address the specific problems faced by large organizations, many organizations also adopted scaled Agile frameworks such as Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile Delivery (DaD).

 

With increased Agile maturity, teams adopted DevOps practices such as Continuous Integration (CI), Automated Builds, and Continuous Deployment (CD), as well as practices as Behaviour-Driven Development (BDD), Test Driven Development (TDD), Acceptance Test Driven Development (ATDD), Automated Unit Tests, and so on...

 

What's The Future Of Agile?

The next big thing in Agile is the Purpose-Driven Development (PDD). There is a clear need to understand enterprise's objectives or purpose, program objectives, and product goals before starting development on any product feature. The product goals, when mapped to primary personas and to enterprise OKRs, bring the maximum benefit. Not only do they drive the product roadmap, they also bring alignment across product stakeholders. 

 

Thus, the future is to bring strategic planning to the product. Leaders should invest time in understanding their customers or users, their problems, and how the product can benefit them. The personas, together with enterprise objectives, should drive the product's purpose or goals, which in turn, should drive the product's roadmap.

 

If product goals no longer align to enterprise objectives or the persona's needs, then the enterprise should have the agility to quickly adapt to the change, move funds or people, and re-plan priorities.

 

Download the FREE Agile templates for strategic planning:

  • The Product Persona Template
  • The Product Vision Template
  • The Product Roadmap Template

 

You may also be interested in these articles...

 

...and below books on Agile and Lean:

Enterprise Agility – Expectations Vs Reality

Posted on by

What is Enterprise Agility? What are the expectations vs the reality of Enterprise Agility (EA)? This article covers the six pillars of EA that sums up the expectations or the future state along with the actual state of things.

"The rate of change is not going to slow down anytime soon. If anything, competition in most industries will probably speed up even more in the next few decades." - John P. Kotter

 

Enterprise Agility - Expectations

Enterprise Agility is centered on the ability of an enterprise to quickly respond to change. Agile enterprises are expected to have:

  • Planning Agility
  • Funding Agility
  • Team Agility
  • Technical Agility
  • Leadership Agility
  • HR Agility

 

Planning Agility

The planning agility represents the flexibility of an enterprise to change its priorities considering changing market conditions or emerging technology trends. The expectation is that an enterprise is able to reprioritize and realign its business priorities quickly with changing market conditions or customers' preferences.

 

Funding Agility

This is closely related to the planning agility. In order to quickly adapt to changing market conditions or emerging technologies, an enterprise must have the flexibility to move its funds or resources around, across teams, departments, and products, depending on the need.

 

Team Agility

Enterprise agility can only be achieved when all teams across an enterprise have adopted the agile mindset, values, and principles. For a team to be agile, they must adapt to change, learn to collaborate, self-organize their work, and consistently deliver high-quality work to generate business value.

 

Technical Agility

Teams achieve technical agility by leveraging engineering practices to deliver high-quality products quickly. Some of these practices include continuous focus to architecture and quality design, test-driven development (TDD), behavior-driven development (BDD), continuous integration (CI), continuous deployment (CD), creating unit tests, and ensuring code quality.

 

Leadership Agility

This is an important competency for enterprise executives and leaders to develop. Leadership agility is the ability to make effective decisions, inspire people, and act with an understanding of what it takes to lead in a rapidly-changing world. With more agility, leaders become more collaborative and proactive in leading teams and driving organizational changes.

 

HR Agility

In an agile enterprise, it is important to integrate HR and other supporting departments such as Finance, Sales, Marketing, etc. with the product development process and introduce agility into their work.

 

Enterprise Agility - The Reality

But, are enterprises “truly agile”? Are you able to quickly adapt to the changing market conditions or emerging technology trends? When your corporate strategy/goals shift, how soon will the change flow from the corporate level to your own products? How soon will funds move from one product to another or from one release train to another?

Let's take a step back and think - does your roadmap even align with your corporate goals? How often do you revisit your product roadmap?

The reality is that change is slow. Larger the organization, more difficult it is to be agile. If the enterprise has adopted Scrum or Kanban, or SAFe, it doesn’t mean that they can quickly adapt to change. With SAFe, the product priorities are revisited on PI boundaries, thus it could take around 10-12 weeks to realign priorities. It may take even more time to move funds and resources between different departments. Enterprises often compromise their agility to have the desired predictability.

 

Post your comments on the expectations vs the reality of Enterprise Agility. Also, check out my latest book, Enterprise Agility with OKRs.

 

More articles:

 

More Books by Aditi Agarwal on Agile and Lean: