Agile Retrospectives

"If you tell the truth, you don't have to remember anything.” - Mark Twain


Agile Value

Wednesday, December 11, 2013 - Ken Schwaber

Every year, organizations spend 4-10% of their revenues on their IT organizations. Value is expected in return for these expenditures.

Here, value is defined as the financial benefit that an organization receives for expenditures. When measured, value can encompass an entire organization, or be constrained, such as to a single division or product line. Regardless, it must encompass those areas affected by the expenditure. 

Value will be a point in time measurement comprised of:

  • revenues per employee – gross revenues per employee
  • employee satisfaction – how satisfied are the employees? After investing in employees, they become a substantial asset and competitive advantage.
  • customer satisfaction – are the customers more or less satisfied than in the past? Finding a new customer is much more costly than satisfying current customers.    

An organization can change value through:

  • products and services that it sells and delivers.
  • systems, both manual and automated, through which it delivers the products and services. 
We focus on the latter.

Philips Lighting 

Philips Lighting, a multi-billion dollar division of Philips Corporation, recently completed a project to “accelerate” its value creation. The project spanned operations from when a quote was given to a customer until the cash was received. The project had two components:

  • Revised business operation, integrated into a new operations flow created through value stream mapping and relentless waste elimination.
  • New software systems, based on Salesforce products, that supported the new business operation.

Each component required the other to succeed. Improved IT operations would have no impact on organizational value unless the business could effectively utilize it.

Value Metric

We have devised a metric that attempts to capture both aspects of an organization’s current ability to create and deliver value. It consists of:

  • operational metrics, measuring an organization’s efficiency. These metrics are heavily slanted toward IT, both the development of software and the deployment of it in the organization. They include flow, cycle time, stabilization, quality, utilization rate, and release cycle time. Business operational efficiency is not included in these measurements, but will be addressed in 2014 as part of the Kotter International (John Kotter) Accelerate! program.
  • organizational metrics, measuring the impact of that efficiency of investment on the marketplace and the value the organization accrues. These metrics are revenue per employee, customer and employee satisfaction, and product/system cost ratio.

The two metrics are combined into a single metric, Agility Index. The Agility Index is a number indicating relative agility, from 1 to 100. It is heavily weighted toward organization value. That is, an organization can be incredibly competent, but if it doesn’t derive marketplace value from the efficiency, the Agility Index is low.

As an organization expends funds on IT, projects, and business improvement, it should expect that this metric would increase.

Traditional project measurement criteria

A traditional project assesses a need and defines a complete set of requirements to satisfy the need. From these requirements, a due date and budget is established. Once these are established, any changes are fit in as possible. All metrics are accumulated against this type of project. Value does not enter the measurement.

Criteria Success
Requirements All requirements stated at the beginning of the project have been satisfied
Budget Budget allocated at the start of the project was not exceeded
Timeline Date for completion of the project was not exceeded

 Agile/Scrum project measurement criteria

Agile/Scrum projects are different. A goal is established: this is the intended impact and objective. A date and funding may be estimated based on past experience, or may emerge experientially as the work progresses. All effort will be directed to achieve the best possible solution to this goal. This initiative is complete when the solution is either created, or it is determined that it cannot be reasonably created at this time.

In the agile project, each Sprint or iteration is a complete project. It has requirements, budget, and due date. At the end, it has a completed set of software functionality. Based on what is completes, another project may or may not be initiated, adding more functionality to the functionality just completed. Each Sprint is measured on its own.

Criteria Success
Confidence of investors in value Confidence of stakeholders, product owner, and developers that the best possible solution was created for the goal of the initiative for the most reasonable amount of funding.
Satisfaction of investors Willingness of stakeholders, product owner, and developers to do this type of initiative again.
Confidence in utility of software Confidence by people using the system or product that it provides a better way of doing work than before.
Satisfaction of customers The degree to which the users look forward to the next solution to helping them do their work better.

3 comments on article "Agile Value"


3/13/2014 5:21 AM

Can we increase the sprint days based on holidays, if yes, what are all advantages & disadvantages.

For example: two week sprint (10 days), if a holiday falls between those days, can we decrease sprint days from 10 to 9?


3/13/2014 5:30 AM

Can we increase the sprint days based on holidays, if yes, what are all advantages & disadvantages.

For example: two week sprint (10 days), if a holiday falls between those days, can we decrease sprint days from 10 to 9?


3/20/2014 4:58 AM

From my end, this is what I have considered:

We defined Sprint Days as Day 1 start of sprint until Day 10 End of sprint (10day sprint)

Now, when a holiday fall within those days, we don't change the End of sprint day, so we still count it as a 10day sprint however, when we compute the capacity for the sprint we consider 9productive days instead of 10productive days within the sprint.

Advantages I can see on this approach is that:

1. Team would have fixed start of sprint(ex. Monday) then fixed end of sprint(ex. Friday) this would mean that Stakeholders wont have to adjust the sprint review day schedule so this helps the stakeholders accommodate sprint reviews for the team -- normally we create a recurring meeting invite to ensure that meetings are plot out

2. Team will be able to consider their task items in consideration of the holiday coming thus once they get back from holiday they would know they have considered it as well


1. Due to the holidays the capacity as well as the velocity of the team will be affected with the reason that they deducted some hours within the 10day sprint

2. There would be inconsistent velocity especially if lots of holidays for succeeding sprint

Please login or register to post comments.

Subscribe to Agile Retrospectives by email