We are looking into capitalizing our agile development costs - however, we have a few teams with different maturity levels. One team uses time estimations with relative ease, other teams use story points with let's say varying success. I want to avoid disrupting the teams' existing methods as much as possible, therefore I would like to use both story points and time estimates as the basis for the capex/opex ratio.

It's been suggested internally to have the teams input the actual values (in story points or time) after the tasks have been completed, so the ratio wouldn't be based on pure estimates.

However, I'm wondering if basing the ratio on story points for some teams and time estimates for other teams would sit well with Finance and the auditors.

Has anybody implemented some kind of "dual track" capitalization (e.g., with provisions for both estimated time and story points being used)?

  • 7
    Can you explain what you mean by "capitalize"? Sounds very buzzwordy. What is your goal, in simple English? Do you think the teams that cannot estimate in story points correctly could estimate in time units correctly? How would that work, given that different people on the team might need a different amount of time for a given story?
    – nvoigt
    Commented Aug 26, 2019 at 8:25
  • By "capitalize", I mean spreading the costs of creating an asset (software, in this case) over its useful life - I'm not a finance type, so there are likely better definitions out there. To do this, we must find a way to track how much of a team's efforts are spent on tasks creating value (capex) versus operational tasks (opex). But not all the teams use the same estimation methods, or show the same level of diligence in updating their work. Commented Aug 26, 2019 at 9:08
  • 1
    So basically you have mixed your project and operating teams and now you try to figure out which ticket belongs to which type?
    – nvoigt
    Commented Aug 26, 2019 at 9:24
  • 1
    Estimates are not expenses. This is definitely an X/Y problem of some sort. What is the underlying problem you're trying to solve? What are the political and business drivers that require you to make changes to your process?
    – Todd A. Jacobs
    Commented Aug 26, 2019 at 17:51
  • 1
    If you have "tasks which are not creating value" why is the company doing them at all? "Operational tasks" do create value - if you didn't do them, the company would soon cease to function. As another comment says this sounds like an XY problem caused by some half-baked (or completely unbaked!) management idea.
    – alephzero
    Commented Aug 26, 2019 at 19:59

3 Answers 3


Different teams estimate in different ways. Even if all teams agreed on story points, a 13 point story in one team does not mean the same as a 13 point story in a different team. It's just a number. That's why one team might have a velocity of 50 and another of 205.7, even if both produce working software at the same speed.

If all you need is capex vs opex, then have the team classify every ticket and calculate the number you need per Team. Team A has 70% based on 70/30 story points and Team B might have 70% as well, based on 209/89 story points. And maybe Team C has 65% based on T-Shirt sizes. They know what the estimate and what it means in real life, so let them figure out how to come up with a ratio.

As for the diligence of updating their tickets with this information: If it's required by management, make sure they do it. If necessary have their manager write them up if they don't. This is work, they get paid for it, they better do it. However, it might be easier to show them what the information is good for. If you generate charts, show them. If you make decisions based on those numbers, let them know. If they know this is useful they may actually be motivated to fill in this data. That's a lot easier than to come after them when they fail.

As a sidenote, because I don't know your requirement, normally things like that are tracked based on facts. Let each team member track the hours spent on each ticket and then calculate your ratio based on facts. That makes the whole issue of estimation and story points and different teams obsolete. Those are complicated because predicting the future is hard. Tracking the past is stupid easy. Maybe you could do that instead.

  • I have seen a lot of people suggest "it is developer's job. they get paid for it, they must do it". That's a very naive view of the world. No one works because they are paid for it. By that logic, our politicians will be holy saints. So, no, forcing people to do anything won't work. It is very easy to explain the reasons and then letting them decide if they still want to do it. If you can't explain the reasons properly, clearly, that task is not important. Commented Aug 27, 2019 at 5:30
  • @jitendragarg So you think I'm naive, because any job can be "explained properly" and then people will want to do it? Have ever been outside our nice little tech bubble? Do you think workers that have a McJob work that because they "see the need"? What about Janitors? Sewer workers? Do you actually know any software developer who'd be like "Oh, capex vs opex, sure, I'll be so happy to do the paperwork, I'll never forget it over more exciting work... like programming"? I agree that explaining is the better way... but sometimes no amount of explaining helps.
    – nvoigt
    Commented Aug 27, 2019 at 5:47
  • Don't be angry, mate. I am talking about the approach. You can be the smartest person in the world, and still approach something with naivety. As for your questions, do tell me, how many of the mcdonald workers or janitors will be okay with "it is your job, you have to do it"? May I redirect you to few of the subreddits about the stories from retail, or restaurant service etc? That's how you get employees who will walk away at moment's notice. Commented Aug 27, 2019 at 6:37
  • 1
    As for the explanation part, "capex vs opex" is the worst way to explain everything. You want to explain something to someone, you must talk their language. Appeal to their mindset. Maybe "if we can find out what are our operational costs, we can reduce them, thus giving you more freedom to do programming instead of attending meetings". Or "client pays us for the program, we need to remove overhead as much as possible, so that you get to finish work faster, we get paid more and everyone enjoys better salary hikes". Commented Aug 27, 2019 at 6:40

One of the simplest ways to do this is to ignore individual developers and instead base all your costs on sprints.

Given a known team and a known sprint duration you have an easy to generate cost figure.

It helps if the team tries to avoid mixing products worked on within sprints as this complicates the cost. But if you can arrange it so that sprints are exclusive to a product then capitalization becomes relatively simple.


One sprint = 10 days

Team size = 5 people

Cost per team member = 500/day

Cost per sprint = 25,000

Team worked on project X for 4 sprints for a cost of 100,000


I'm going to frame challenge a bit. This is a Finance and Legal question, not a PM question.

What will be 'acceptable to auditors' depends on if you're publicly traded and if so what regulatory bodies you are subject to.

e.g., for GAAP SEC Filings in the US you will find language to the effect of "time tracked directly to the project." I think you would have a hard time convincing auditors with an old school mindset that your reverse estimation algorithm meets that requirement.

Also while one appreciates the challenge of getting programmers to do regular timesheets, it does seem hard to convince finance that filling out a timesheet once a week would be an unreasonable burden on the team.

If you're not publicly traded, one wonders what the point of the extra work would be? Potential investors/buyers are unlikely to be 'fooled' by the accounting trick and will value your IP based on their assessment of true market potential regardless of what your balance sheet says.

  • I agree it's a stretch to put it in PM, but that's kind of where the question fell here so I figured I'd get a PM perspective on it. In any case, the Finance and Legal implications aren't my purview, I'm just the guy who needs to get something done. Let's say I'm not looking for a definite answer here and more for comparable/similar solutions that may have been used by others. Commented Aug 28, 2019 at 2:37
  • 1
    @benoitauger well, my comparable real world situation in trying to do what you're asking is we got an audit finding and had to get a timesheet system ;)
    – Affe
    Commented Aug 28, 2019 at 15:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.