Throughput Accounting
Main variables
- T = Throughput = fresh money coming in to the system
- OE = Operating Expenses = money going out to keep the system going (E.g. wages, energy costs, rent....)
- I = Investment = money that is tied up in the system to be able to generate Throughput (E.g. requirements, machines, unfinished/unsold work...)
What we try to optimize
- NP = Net Profit = T - OE
- ROI = Return On Investment = NP / I = (T - OE) / I
Of course, time is always an important factor whenever money is involved. One first chooses the period over which one wants to reason: one release, one year, the life of the product/project...
We can improve by (in order of importance)
- Increase T, unless the OE and/or I increase required is too big
- Decrease I, unless it decreases T or increases OE too much
- Decrease OE, unless it decreases T or increases I
Tying this back to Agile Software Development
If we believe that these are the right goals, which metrics can we use to tie our work back to the results that work will have? The metrics I use are:
- SP = Story points = an abstract measure of the intrinsic complexity (effort required to implement) of a story. This is estimated by developers
- Velocity = story points / man day. This is measured at the end of every release
- BP = Business points = an abstract measure of the expected value of the story. This is estimated by the customer(s)
- V = Value of the project/product. For products this is simply T, the sales of the product. For internal projects it could be the increase in T and/or decrease in OE or I of the company caused by the project.
So... for one release
- MD = man days per release = sum(SP) / velocity
- OE = (MD x cost of a man day) + fixed costs (rent, energy...)
- T = V = BP x X ? (where X = "Business velocity")
- I = ???
How can we optimize our system?
- Find the stories with high Business Value (in story writing and planning game): developers+customer
- Find the stories with low Story Points (in story writing and planning game): developers+customer
- Improve velocity (by refactoring, buying better tools, learning more about technology or domain...): developers
- Improve business velocity (by selling the same features to more customers, by selling at a higher price...): customer
Open questions
- Can we measure V?
- If so, can we see if there is indeed a correlation between changes in BP and V? And thus, we can measure business velocity? Business Velocity = money earned / business point
- How can we express and measure Investment in IT projects?
- What are examples of investment in (agile) projects?
- Setting up an automated build system?
- Setting up an automated acceptance testing system?
- Refactoring code?
- Writing documentation?
- Unfinished work? Requirements, analysis, design, code... not sold?
- Add your examples
|
