Please note that you may wish to read our article on Demystifying CapEx before diving into this one as there is some knowledge that will be assumed, rather than repeated.

Introduction

Several readers pointed out that one of the most important parts of the article on Demystifying CapEx was buried at the bottom, and deserved further exploration. Specifically:

💡 Why does “agile” make this harder?

Agile complicates CapEx tracking because it’s fluid. It’s iterative nature means that defining the lines between specific project phases or teams isn’t always as clear-cut as Waterfall methodologies. Often, the same teams responsible for updating the mobile app are also tasked with developing new features.

This article expands on Demystifying CapEx. It explores key principles to enable effective, accurate, and painless CapEx across agile and traditional initiatives in your organization to help you track CapEx effectively whilst maintaining the benefits of agile working.

Breakdown the “project”

The first challenge organizations often come across is confusion about whether a given “agile project” is capitalizable. This is because typically, agile “projects” lose the deterministic nature of a waterfall/traditional project. That is to say, it is less likely to have a clear beginning and end with a clearly definable, singular output. This is often because funding has shifted to support durable teams, rather than specific outcomes.

In traditional project delivery, it’s easier to point at a given project and say – “This project is building this capitalizable asset, therefore it is x% capitalizable”.

In agile delivery, we might look at the mobile app team (for example) and say – “Well some of their time is spent building new features, some of it is spent supporting existing features, and some of it is spent fixing bugs”. We might know that the new feature work is capitalizable, but how do we accurately distinguish between these two types of work?

It’s tempting at this point to think – “Why don’t we just allocate x% of the agile project / team’s time to CapEx?” – but extreme caution should be exercised with this sort of approach. Failure to accurately account for capitalizable expenditure could result in artificial balance sheet inflation, a practice that was at the heart of the Enron scandal.

Instead, we need to look at ways to breakdown the project.

The simplest way to do this is typically to encourage teams to book time at the Epic level. Noting that when we say “Epic” here, we’re talking about the highest level of the work breakdown structure within a given team.

This diagram illustrates the difference in the way work is planned and funded between agile and waterfall initiatives.

This diagram illustrates the way organizations should think about booking time between different types of work.

… but don’t break it down too far

We find that Epic is a great level to break the project/agile team too. But you should avoid the temptation to allow users to book at any level (e.g. Story or Bug). This has two big downfalls:

• It makes the time recording process itself tedious for teams as they attempt to attribute their time across potentially hundreds of stories and tasks that they worked on in a given week
• The proliferation of data at enterprise scale will quickly mean you need a data warehouse to house your time recording data. With 1,000 people booking to 50 activities a week, you’ll have at least 2.5 million rows of data per year. This additional granularity causes significant processing pain, with no clear benefit.

Make it easy for people

In some ways, this is the most important tip to maximize accurate CapEx allocation. Getting this right is the difference between time recording being a streamlined, painless background activity and time recording being a painful nightmare that your teams resent and wastes huge amounts of time.

Three straightforward top tips to follow here:

1. Your timesheets solution has a real-time integration with your task management tooling (e.g. Jira/ADO). Its critical to ensure that your teams can create an Epic in Jira/ADO and instantly book time to it. This allows users to book time as they go, rather than spending time on a Friday afternoon attempting to recall how and where they spent their time.
2. Make sure that users can search by the name of the issue they’re looking for and/or the issue key. Issues have a habit of changing names, but the issue key is constant.
3. Ensure that users can also book time straight from the Jira or Azure DevOps issue. Ideally, this should be a direct link from the issue to their time sheet. This will encourage users to build a habit of booking time while working on a given issue.

Create “buckets” for production support

An easy way to allow users to book production support time is to create dedicated epics within your initiatives. Production support related to the initiative can be logged against these Epics. These Epics are typically long lived, and 100% OpEx. If your organization typically undertakes production support that is not related to an initiative, creating separate orphaned epics that are aligned to the products being supported is a good approach.

Depending on the structure of your portfolio, its typically best practice to create a production support epic per initiative. This requires increased specificity where this type of time is recorded, rather than just one generic bucket. This helps to encourage people to resist the temptation to book to production support as a default option.

Be sure to provide clear, common guidelines about the types of activities you expect to fall under these buckets to ensure there is no confusion.

Avoid incremental time allocation

There are essentially two different types of time allocation. Incremental and retroactive.

Incremental – we can think of this as a “book time as you go”. This method requires people to book time as they spend it. They might open a given ticket, do some work on it, and then, ideally, book time.

Retroactive – this is the more traditional approach where people complete something akin to a “timesheet” at the end a week that they are required to “submit” by a given time. Sometimes this timesheet might subsequently be “approved” by a line manager. Importantly, a retroactive timesheet will typically require the user to account for how they spent all of their working time.

The key difference between these two approaches is that incremental time booking rarely results in users allocating all of their time. Typically, with the incremental approach, users sporadically record time against tickets when they remember. At the end of the period, organizations often end up with a patchwork of time booking that is substantially less than the total hours worked. We typically see this results in organizations “chasing their tails” trying to get teams to fully allocate their time correctly. As time wears on, people are less able to recall how they spent their time, causing further issues. This approach is even more problematic where you have 3rd parties booking time as part of the invoicing process.

Conversely, retroactive starts from the position that the user worked (let’s say) 40 hours per week and requires them to allocate all of their time. This approach universally results in improved coverage. Where organizations successfully connect this approach with the tips for making it easy for people, you end up with a best of both worlds set up. Resources can book time as they go if they’re diligent (straight from the ticket they’re working on), but must submit a complete timesheet at the end of the week.

Embed transparency

Ensuring transparency, particularly across senior management and executive teams drives responsibility and accountability. Transparency about who is booking to what, compliance, spend and capex allocation itself will all drive improved behavior.

Anything you can do to avoid the time sheeting process becoming a black box will drive improved data quality standards.

Conclusion

Mastering CapEx tracking in an agile environment requires thoughtful structuring and streamlined processes that make time allocation easy for teams. By implementing the steps above, your organization can ensure accurate and efficient financial reporting that supports strategic decision-making whilst ensuring team buy-in to maintain accuracy.

Want to see how Kiplot helps organizations with effective time tracking and CapEx allocation? Explore Kiplot’s time tracking capability from the features section of our website.