My experiences with abstracted units of measurement for estimated work have always failed or caused problems when the people in finance find them.

Part of this may be due to poor communication within the organizations that I’ve worked, but I think the natural tendency for someone in the CFO’s org chart is to want to turn those abstract units of work into something that can be used as a planned capital expenditure.

It is my understanding that to accountants, paying software projects are the same as paying for any other durable good. On their spreadsheets they budget purchasing equipment the same way they do for purchasing software.

It’s complicated and there are people who understand that domain far better than I do. What I do know is they want to know how much a project is going to cost when they define their budgets. Changing the cost or the scope seems to be a big no-no. GAAP accounting may be the antithesis of agile software planning.

As a result of the accounting rules; the points, the ideal work days, the glimzarks, or whatever metaphor for work the software people want to call them turn into hours and then ultimately into dollars. Hide the points as much as they will, the people who pay the bills will find some numbers and they will likely adamantly insist that those points have some dollar value.

How do we move beyond agility? I don’t know. It’s a domain that I’ve contemplated for a while. I think the needs of accounting and finance need to be taken into account and reconciled before we can move beyond agility.

In practice, I think that capitalized abstracted planning can be done. What needs to happen though is that the scope of the project must be abstracted sufficiently to allow the project enough room to evolve the details of the implementation as the project is in process. The challenge there is getting everyone on the same page. Getting buy in from people in vastly different facets of an organization can be very difficult in practice.

To an accountant, waterfall is an ideal methodology.