Picture of George Washington on dollar bill

Sometimes it is all about the money!

In our interlude, I posited that there are questions that organizations need to ask and find a mechanism to answer. Some of the feedback I received suggested that the questions weren’t agile or weren’t agile enough. To some, only the outcome matters, not the cost or the amount of time it takes to deliver the functionality requested. The perspective of a team can be very parochial, focused on delivering what is in front of them; however, their existence is tied to more than customer satisfaction.   All organizations are tied to cost and productivity. Understanding the impact and return on effort, raw material and capital within a company that is ultimately needed to deliver the organization’s products and services define ROI and profitability.

I caught the tail end of a business story on the BBC recently. A banking startup was focusing on client acquisition and had calculated that they were losing 50 £ to acquire each client.  Regardless of the depth of their funding, there is only so long they can continue the pace without cost or revenue offsets. Calculating financial metrics is a critical first step for deciding which work leads to the best outcome for the organization and, in the long run, the team and every individual on the team.

Tough questions every agile organization will be asked include:

  1.      Where should we spend our limited financial resources?

    Metric: ROI = Revenue / Cost (Cost is the sum of direct labor, overhead, tools, and hardware)

    Why Care: ROI provides direct evidence of investment gains as compared to cost and provides a guide for an organization to maximize their return.

    Notes: ROI is not an absolute discriminator.  Some products (or modules or features) are experimental and need to be funded until the experiment provides the information it was designed to expose (you do design your experiments, don’t you?). Others are enablers for other higher ROI products.  In many cases absolute precision is not needed to identify focus areas for more in-depth study.

    2.      One team, two teams or …. — Are we staffed correctly?

    Metric: Backlog Consumption = Backlog Size Current Period / Backlog Size Current Period-1

    Why Care: Changes in backlog size are a proxy for service demand – in software development and maintenance that equates to staff.  Backlogs that are growing (or shrinking) at above normal levels indicate potential staffing issues.

    Notes: This metric tracks items in the backlog, not size. Backlogs for on-going products tend to establish a steady state with stories entering, exiting and decomposing.  This is not true very early or very late in a product where staffing models are often in flux. Shocks to the system are easily identified and analyzed to determine the root cause.

    3.      Can you forecast budget and staffing needs based on your product backlog?

    Metric: Costed or Valued Backlog integrated with Product Roadmaps.

    Why Care: The cost or value metric tracks pent-up demand, when tracked against the product roadmap (product management’s view of the future). If compared to the actual spend the ratio is a proxy for staffing.

    Note:  This metric is the most future-facing of the Cost/Predictive Accounting metrics shown here.  It can be leveraged with forecast ROI to predicting staffing and investment decisions. 

The quote, “follow the money” (from All the President’s Men) is apropos for many conversations and questions spawned by senior leadership.   These questions can’t be ignored even if you don’t think they feel agile.