Understanding Cost in a SAFe World
In a textbook SAFe implementation, Lean Portfolio Management allocated a budget to each Value Stream and consequently each Agile Release Train (ART). The ART’s Product Manager works with the ART’s stakeholders to priorities the work that consumes that budget. The ART plans and executes against these priorities and no one worries about how much it costs to deliver any specific feature. However, there is often a difference between the ideal SAFe implementation and your current reality and one of those differences can be an expectation that the ART can articulate the cost of delivering a given feature. This is especially likely to be true if your ART is inside an organisation that still uses project based funding.
Organisations can be quick to respond to these challenges in the same way they have in the past by asking individuals to fill out timesheets with specific project and activity codes. In a world where we want delivery to be a team accountability and estimation to be in story points this feels like a huge step backwards. So what might an alternative look like if we were to use information that we have readily available and minimise the overhead on the teams to collect data solely for costing purposes?
An approach I have had a lot of success with is the cost per story point model. The idea is that I know the cost of the people working on the ART and I know the historical velocity of the ART and therefore I know the cost per story point. If I then want to understand the “cost” of a feature I can take the normalised points estimate from PI Planning and multiply it by the cost per story point and I will have a pretty good approximation. If I want to understand the “actual” cost of a delivered feature, I can ask the teams to advise of any significant surprises they had during delivery, that meant there was probably more or less effort required than what was estimated at PI Planning.
As simple as all this sounds, there are some nuances, that may or may not be material, but will certainly make your numbers more defendable. If you are geeky like me, you might find this whitepaper useful in building a robust cost per story point model for your Agile Release Train.