“Always show your working out!” was the mantra of my maths teacher in senior school. This series of blog posts “On the Nature of Lean Portfolios” is an exploration of Lean Portfolios. It is the thought processes running through my mind, exploring the possibilities so that I understand why things are happening rather than just doing those things blindly. It is not intended to be a fait-accompli presentation of the Solutions within Lean Portfolios but an exploration of the Problems to understand whether the Solutions make sense. There are no guarantees that these discussions are correct, but I am hopeful that the journey of exploration itself will prove educational as things are learnt on the way.
Estimating Expense or Effort?
I thought I was going to leave the Budgeting and Road-mapping topic but there’s one last thing to discuss that has been lurking at the back of my mind all through the previous discussions. It’s not an easy topic to write about because there are no right answers, the discussions are circular which makes it hard to find a sensible point at which to start and end, and finally regardless of conclusions drawn people will continue doing what they’ve always done. Regardless of these difficulties, it’s a topic worth discussing. One of the other disconnects within Participatory Budgeting has been that Participatory Budgeting discusses investment in terms of monetary Expense whereas Roadmaps need Effort estimates.
Which should it be?
A Simple Relationship
It is possible to convert between Expense and Effort.
Conversion between Effort and Expense
- The Train PI Cost is known from the wage bill1 and PI length.
- The Train Velocity is known from historic data on what they’ve achieved in previous Program Increments.
This leaves either Item Effort or Item Expense as the variables. If one variable can be estimated then the other variable can be calculated as a simple linear scaling.
There is no complex calculation, the calculation is commutative and can be run in either direction, the calculation has no preference towards one variable or the other from a mathematical standpoint. Which means that from a mathematical standpoint there is no bias towards either Expense or Effort.
What are you actually estimating?
A very carefully phrased title; what is the quantity that you’re actually estimating? As we’ve seen it’s possible to translate easily between the different units, so what units were the estimation actually performed in?
- If the Money was estimated through true relative estimation, “X is roughly the same as Y, and Y cost $Z so X will also cost $Z” then we’ve never left the money dimension and it might make sense to keep talking money.
- If the Money was estimated through an effort calculation “X is roughly the same as Y, and Y took Z months of effort, so X will also take Z months” then the estimate was in the effort dimension and it might make sense to keep talking effort rather than converting to money.
- If the Money was estimated through the time calculation “X is going to take 3 months, and 3 months of $Y wages will cost $Z” then the estimate was in time, which is almost the same as effort, but not quite. We’ll come back to this later.
Since the conversion is trivial the dimension that the estimate originates in doesn’t have any immediate impact on whether it should be Cost or Capacity.
Whilst you can get to Money by estimating Effort; the reverse calculation feels wrong. You wouldn’t estimate Money and convert it to Effort, that feels like an amount of Effort is being dictated down to the organisation rather than understanding how much effort is involved.
Which Dimension Can You Estimate In?
For trains that don’t exist there is no historic velocity data to inform a capacity estimate, therefore there is nothing to compare effort against, so pure relative estimation of Money makes sense. Given that Participatory Budgeting is a “clean sheet” budgeting process, you could argue that until Participatory Budgeting is complete the Development Value Streams and Agile Release Trains don’t exist for the next budgeting period and therefore the discussions have to be in Money, but most Participatory Budgeting discussions don’t drastically change the Development Value Stream network and historic data can be extrapolated to provide a reasonable indication of the capacity of the pieces of the future Development Value Stream network.
For trains that do exist, historic velocity data should be available from which to estimate future capacity. Historic work will exist with effort infromation from which to realtively estimate future work. An Expense estimate can be derived by through the standard trivial calculation that has been mentioned previously.
What do you need the estimates for?
Participatory budgeting wants Expense; if the group decides that the work item should be funded then the expense gets deducted from the total available funds and transferred to the Development Value Streams that will contribute to doing the work item.
Road mapping could utilise either Expense or Effort; it’s just reserving space within a Program Increment on the roadmap that could be plotted out using either dimension.
The cost of the Program Increment is dictated by the budgeting process; the Capacity comes from the historic data. The relationship between PI Cost and PI Capacity is not fixed, the conversion is a reflection of the knowledge and ability of the Agile Release Train to make changes, the ability of The Architecture to adapt to incorporate those changes and the Continuous Delivery Pipeline to release those changes to market; knowledgeable people with an easily changeable codebase and an efficient build-test-deploy pipeline should deliver a greater capacity for a given cost compared to unknowledgeable people with a poor supporting environment. The conversion is trivial but if the estimates are all in the Expense dimension it doesn’t necessarily take into account historic information that shows the Agile Release Trains improving; this is explanation for why it was previously mentioned that Time and Effort are not the same thing.
Both Expense and Effort are needed, but again the conversion is trivial. Use of Effort estimates instead of Expense allows the organisation to see improvements through a changing velocity.
Separation of Effort from Expense
SAFe deliberately separates the money, the funding, from the work. The money is invested in Development Value Streams that employ people, either directly as salaried staff or indirectly through external suppliers, and the money also pays for the necessary licenses, infrastructure, equipment, etc… to allow the employed people to do their work. Employing people generates capacity which can be used to do work. This is very powerful because it creates more stability in the teams within the Development Value Stream which gives them a greater chance of growing into high performing teams and developing predictable metrics; it also changes the direction of portfolio conversations from “where has the money gone?” to “what is the most valuable work we can do?”
A piece of work may have a monetary cost associated with it, but choosing not to do the piece of work doesn’t get the money back for complete freedom of investment elsewhere, the money is invested in the people and will be paid out through the wage bill, regardless of the work being done. Choosing not to do a piece of work frees up capacity that can be used on other pieces of work by this group of people. To get the money back the funding to the Development Value Stream needs to be changed, the implication of which is structural change to the workforce.
The separation of Money from Work is probably the argument as to why the estimates should be Capacity estimates rather than Cost. Money is handled through a different feedback cycle to the work. Lean Portfolio Managment and the Participatory Budgeting process provide advice to the Functional Hierarchy so that it provides the right workforce for assembling the Development Value Stream Network3. Evolving the hierarchy, changing the workforce, is always slow.
Handling Additional Expenses
However, Effort estimates don’t include additional Expenses that a work item might incur.
As an Epic changes the organisation it might change the structure of the outgoing costs.
- Recurring Costs : The Epic adds a new recurring cost, e.g. Cloud subscription, Licensing payment, to the Development Value Stream. These would need to be absorbed into the Development Value Stream. The add to the Development Value Streams baseline costs (the BSI of participatory budgeting).
- One-off Costs : The Epic will incur a one-off cost. If the Epic is approved and funds are transferred to the Development Value Stream to create capacity so that the Epic could be done in the future, then the Development Value Stream has to reserve some of the funds to spend on the one-off cost if the Epic gets approved.
Not all of an Epics funding need be used to employ staff; some might be reserved for other expenses. The Epic needs to provide simple advice to the Development Value Stream on the breakdown of costs and their nature, i.e. one-off or recurring. The Development Value Stream can adjust how it’s spends the money that is invested in it to cover the additional expenses.
This is an argument for Expenses over pure Effort.
Conclusions
As I mentioned are the beginnin it’s not an easy topic to write about because there are no right answers, the discussions are circular, drawing a definitive conclusion is hard. Probably the only conclusion that can be drawn is that you are going to need both Effort and Expense and that whilst conversion is simple there are a myriad of factors that affect one and need to be converted across to the other. Expense is needed for budgeting to ensure that the money gets allocated to the right Development Value Streams and that can capture the additional expenses over and above development. Effort is needed to reserve space on the roadmap for forecasting and prediction in the time dimension. Estimating Effort, converting to Expense and adding addition expenses captures more of the nuance that arise from PI Cost and PI Capacity being loosely coupled and the conversion factor between being influenced by the Agile Release Train’s knowledge and tool chain.
Personally, I don’t like discussing Money; it leads people into thinking that they can move the money around when they can’t. The money has been invested in the workforce, either directly through employed staff or indirectly through contracted suppliers. It’s a different feedback loop that moves the investments around, not the work loop, although the investment loop is influenced by the future work being considered through the process of Participatory Budgeting.
However, you can’t turn back the tide4. If the execs want to talk money then they’re going to talk money even if it is the wrong thing to be discussing. Do the conversions from money to effort and effort to money and slowly educate them about the complexity of the topic.
What this does show is that all of these calculations are often being done with the most nebulous of Estimates and that other than setting up an investment profile to try to ensure that the money is directed towards where the perceived demand is, the estimates shouldn’t be used for anything more concrete.
Trying to make the work conform to a cost estimate is also a Fools Errand5 and should be avoided; change the conversation around to “have we got value for the money/effort that the work has consumed?”
Next Steps
This digression completes the series of topics around Participatory Budgeting and Road-mapping. The next space to explore is going to be OKRs, Objective and Key Results and then on to looking at the Lifecycle of Epics
#1 Wage bill plus other expenses such as licenses, buildings, materiel, etc… all of which are usually stable and predictable
#2 This is a simplification; Police, Fire and Medical services are examples of persistent teams in local government that require renewed budget each time
#3 Balancing The Dual Operating System, SAFe Fellow Ian Spence
#4 King Canute and the tide
#5 Fools Errand, a pointless undertaking