A really simple approach to CapEx & OpEx financial accounting with Scrum. Why is this needed? The apparent mismatch between standard financial accounting practices and agile ways of working. Specifically CapEx and OpEx accounting, which is often a very important practice in (larger) organizations. This distinction seems to be at odds with having a more mixed flow of work compared to the days when we used to make a big design up front (BDUF). After reading the great article by fellow PST John Gillespie titled CapEx & OpEx through a Lean lens [1], I felt the need to rephrase in my own terms to give a practical starting point for Scrum Teams struggling with this concept which can lead to an administrative burden if we aren’t careful.

Disclaimer: I am by no means a financial expert and the below article is just as much me trying to make sense of stuff as potentially helpful to practitioners in the wild. The proposed practices are by no means a panacea. Talk to your financial experts and work together to improve! The sources used are targeted at software development for INTERNAL use. I am not currently sure how this would translate to SAAS or app development.


Difference between CapEx & OpEx highly simplified

In short: CapEx is all development (innovation) work. OpEx is all ‘preliminary’ work, and all maintenance. So a super simplified way to track/account these is to budget all Product Owner activities as OpEx and all Development Team activities as CapEx. For a deeper dive and detailed background, also see the extensive SAFe CapEx/OpEx article [2].

Capital Expenses (CapEx)

Capital Expenses should account for all in-sprint development activities. So all cost incurred by the Development Team in creating the Done Increment should be under CapEx. Simply tracking all expenses like Development Team pay & costs needed for specific Sprint Goals should suffice.

Operational Expenses (OpEx)

Operational Expenses are a bit more complicated, since we want to account for both preliminary work as well as maintenance. Taking this approach there are rougly two types of work in Scrum:

  1. Maintenance work done by the Development Team. When a team has the full responsibility to build-ship-run, there’s some maintenance to be done. Most of the time also some small rework/bugfixing even though we strive for high quality through technical excellence.
  2. All Product Backlog management activities. This includes all forms of refinement, stakeholder meetings (storymapping, business value estimation, etc) and whatever else you can think of.

Simple approach to tracking OpEx in a Scrum Development team

Since we can simply account for all Product Owner activities as OpEx, the biggest challenge lies in getting a clear insight in the OpEx part of the Development Team work. Luckily, there are some great practices that teams can apply to account for these kinds of costs in a lightweight manner.

In Sprint Planning we also have to take into account the time spent on refinement and maintenance activities for the upcoming Sprint. How do most teams deal with this? By applying a simple rule of thumb to start with, and using the Inspect & Adapt loop of Scrum to adjust when needed.

Maintenance accounting in Sprint

Most teams have a good sense of how much time of the Sprint is normally spent on maintenance work. This is kept ‘free’ in the Sprint when crafting the Sprint plan. Sometimes it is put on the Sprint Backlog for transparency. For any new team with no clue, this is mostly 10-20% of their planning. And as such, 10-20% of their cost should be shifted to OpEx. 

Refinement accounting in Sprint

In Scrum, the act of Product Backlog [3] refinement is defined as follows:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. 

https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

Since the Development team is often needed for these refinement activities, we might choose to account for them as OpEx. If we do so, we can use guidance from the Scrum Guide again to define a starting point as a rule of thumb:

Refinement usually consumes no more than 10% of the capacity of the Development Team.

https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog

So for most teams, CapEx is about 70-80% of their Development Team cost, plus the in Sprint additional costs. 20-30% of their Development Team cost is OpEx, plus additional refinement cost.

Additional costs?

Examples of additional costs:

  • Potential additional CapEx: specific tools or new technology is needed IN SPRINT to try something out or implement new functionality.
  • Potential additional OpEx: costs related to user & market research, refinement sessions, focus groups, travel to user locations, etc.

Tracking CapEx & OpEx – pitfalls

When accepting the compromise or reality of this kind of expense tracking, there are some pitfalls to watch out for. In the constant move towards more organizational agility, we should be aware of even more simple solutions, like just labelling everything OpEx. Also, while we are in the situation of tracking the different expenses, we should not create extra overhead for the people involved. Again, always striving for the most simple, frictionless implementation.

In Agile accounting, all cost should be Operational

In discussing all this, you might have thought to yourself: “But in agile we want to keep things simple, and we don’t discern between phases in product development!”. A possible simplified end state is to see it as a sunk cost and since we never can truly be sure about the ROI of our work, we should account for it as ‘gone’.  For more on this, read Why More CFO’s are shifting their investment from CapEx to OpEx [4]. And while that is true, it may be a requirement in your organization to account in this way. And it may very well be that the organization is not ready (yet) to completely put all cost under Operational Expense (OpEx) and be done with it.

We should track every hour of work under the right category

Using the guidelines and ideas laid out earlier in this article, it is a small step to forcing your team(s) to track every spent hour under the right category. While this seems sensible (we should have a precise and watertight financial administration) it is quite destructive for the effectiveness of a team. Since the teams are doing complex creative work (or we wouldn’t need Scrum or Agile), they need the maximum possible attention for actually DOING the work and finding the best possible solution.

How then to get it ‘as right as possible’? First off, talk to your finance department about what is actually needed (by law) and find out what the leeway is in ‘getting it precise’.  If you need more than a ‘general’ average split in your company you can apply various tactics. From reviewing the split after each sprint and correcting for actual spent time/cost, to having a labeling in the backlog, where items are tracked as ‘innovation’ (CapEx) or ‘Maintenance’  (OpEx). Unforseen maintenance can be added to the Sprint Backlog as ‘Maintenance’. Having a digital tracking tool helps for traceability and reporting here, but just keeping an excel up to date is possible too, depending on your business and market regulation/law.

Simply Refusing as this is not agile

This option is often tried out by inexperienced professionals or purists, who fail to apply the Scrum Values to this problem. Instead of collaborating with the people and departments involved from a place of Respect, Openness & mutual Commitment to do the right thing for the Organization, they create tension, in- and out-group stress and diminish the potential mandate and self-organization. Because this will escalate and if this is the way your organization does their accounting, you will first need to deal with it in the most agile way possible (at that time) and establish trust. From that point on, you can collaborate to improve and simplify.

CapEx and OpEx in Scrum, a multitude of options and a journey to simplicity

In conclusion, there are a lot of options to figure out this accounting stuff when trying to do Scrum. In striving for simplicity, we should work together to find the simplest current possible solution and envision even simpler ways we could step towards as a future even more simple approach.

What are your experiences with CapEx & OpEx in Scrum? Are there pitfalls you’d like to add, or different practical appraoches to add?  Do you have additional questions or improvements for this article? Let me know in the comments!


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.