Story points into the balance sheet

Here I’m going through experiences connected to software development and technology, as it is sometimes hard to get a good connection between technology and financials. What is said here also applies for other development, the fundamentals are the same.

Labor costs are an essential component of a company's expenses and are reflected on the balance sheet in a specific way, depending on the stage of payment and the nature of the labor costs.

Labor costs, story point and hours

Labor costs are a significant component of a company's expenses and play a crucial role in its financial health. Properly accounting for labor costs on the balance sheet ensures that the financial position of the company accurately reflects its obligations and financial resources related to employee compensation.

Therefore, there can be friction between the Financial and Tech departments. The Financial department wants hours (they want €), and the Tech department works with story points. Story point is a non-normalized value that indicates the complexity of delivering work. In short, one way of doing it is that the development team including QA estimates each requirement/story for complexity on a scale from 1-20 if it is more than 20 then the story needs to be split, this can be called Poker Planning.

In the Agile community measuring hours is a big NO-NO and for techies is not about how much you work on it is, it’s about solving a problem.

How have I solved it during my carrier?

I have agreed with the financial department on the requirements of the “working hours”.

As an example, the agreement could look like this:

Capitalization of Software especially in-house built

• These capitalization accounting rules provide guidance for the treatment of costs at different stages of software development life cycle

Discovery: Expense All Costs (ITIL Service Strategy)

•  Resourcing, feasibility studies, RFP’s, all kind of evaluation and planning

Engineering: Capitalize Select Costs (ITIL Service Design and Service Transition)

• Material and services that engineers consumes to produce code
• Payroll costs of engineers producing code
•  Possible interest cost for funding the project
• Special care needs to be applied if data conversion costs are capitalized

Other overhead cost like project management steering groups training and other overhead are expenses as incurred and not to be capitalized.

Running the software: Expense All Costs (ITIL Service Operations and Continuous Improvement)

•  Evolutive maintenance, training, and incident management costs, must be charged to expense as incurred

When to Capitalize Costs:

Project Approval and Commitment

• Capitalization of costs should commence after the Discovery has been completed and management has committed to funding the project. This commitment typically occurs when the project is approved into the Project Portfolio Management (PPM)
• The project must be considered probable for completion, and the software must be intended for its designated function

Completion of Substantial Testing

•  Capitalization of costs should conclude when all substantial testing of the software during Engineering, and especially during Service Transition, has been completed. A Release Test Report, produced by QA, could be a critical indicator that the software is ready for its intended purpose

Cancellation or Abandonment

• In the absence of evidence to the contrary, uncompleted software is assumed to have no fair value
•  If it becomes improbable that a project will be completed, capitalization of costs must cease immediately
•  Impairment testing should be conducted on the costs already capitalized to determine whether any adjustments are required
• The carrying amount of the software asset should be adjusted to the lower of its carrying amount or fair value (less costs to sell) at the point of abandonment

What does this mean?

In short:

1. You need to have a project plan and report on progress, only cost related to code that ends up in production can be capitalized
2. You need to have dedicated testers testing the software before release and producing a test report
3. When the software is in production then you report to finance the story points on getting the software to production abiding to the rules mentioned above
4. Finance calculates the monetary value of the story point and capitalizes it
5. Make sure you have an audit trail from project plan-requirements-test result-release for each feature/story

How to get a monetary value on a story point?

The execution is easy, the selling is hard. In essence the developers and QA-engineers log effective hours (hours writing code or testing functionalities) on stories. These stories have already been estimated with story points. Logging the hours for a while (until the value is stable) and collecting the story points released to production will give a fairly accurate estimate on average how many hours of work is in a story point. There will be a time difference between hours in development and story points in the release, eventually it will even out over time.  We should remember that accounting should give a fair and reasonable accurate view of the financials of the company, it is not exact science like math. Challenges come in communicating the following requirements to the tech organization:

• log only hours doing coding and testing, not planning and meetings
• it is totally alright that somedays you only log 2 hours as there are a lot of other tasks
• log effective hours, not weeks or days
• We will NOT use the hours for performance review

Capitalization trap

What is an eye opener for many developers is when I explained how a balance sheet works, and why companies can’t afford to get rid of legacy software that have been heavily capitalized.

“Imagine that the IFRS balance sheet value for an in-house built legacy software is 40M€ and the company is making 1M€/year profit, what do think will happen if we scrap it and build something new and take it as a cost in these years result.”

This is one of the reasons we still work with old software that is hard to maintain and develop further, nobody wants to declare a 39M€ loss. So many times, it’s the CFO that decides what technology is in use, capitalization of technology can be a trap. A trap many start-ups and especially scale-ups are stuck in if they have a need to show a good result and can’t get rid of the Proof-of-Concept that has ended up being the production system. At the end of the day the legacy software still generates revenue.

The capitalization trap can also be realized before the software is even released. In the case that the project has been going on for many years, a lot of costs have been put as investments in the balance sheet. You might be in a situation were closing the project and admitting that this will not ever generate any value would result in a negative write-off that again impacts the result of the year. 

Disclaimer

What is discussed here on a general level is one way of fulfilling the requirements from but please always check local rules and regulations related to capitalization of development expenses for further guidance as the requirements can be quite strict.

There might be circumstances that makes the approach not viable.