Re: [scrumdevelopment] Re: GAAP and Agile
- I'd love to see what the IRS does with this if they ever audit on some tax issue like the domestic production deduction (only applicable to software product development). I'm not exactly sure how the 10 minutes or so a day it takes to track time to projects and activities (i.e. "coding" etc.) for billing/costing/tax purposes is non-agile provided it is not used to measure project progress.
On Wed, Dec 2, 2009 at 12:26 PM, maxwell_keeler <maxk@...> wrote:
Our company is piloting a process for capitalizing work on stories without tracking hours. We use user story "story points" as the basis for accounting. Here's generally how it works:
1. For initiatives that qualify as candidates for capitalization we determine the members of the team (developers, scrum master and product owner work is generally not cap'able).
2. For each team member, we determine how much of their time was spent dedicated to the lifespan of the initiative (ideally it's 100%, but sometime resources are shared or people join after work has started or leave before it's launched).
3. The we make general assumptions about what % of team time is spent coding. I think it's good to be conservative, I would estimate no more than 50% in most cases.
4. We then determine the average velocity of the team during the initiatives development (let's say 35 story points per iteration).
5. We then divide the total story points spent on the initiative by that number (let's say the whole thing took 350 points, that would mean 10 dedicated sprints of work).
6. Our sprints are 2 weeks, so we can use that to determine how many hours per sprint a team member has, so in this case let's say 80 per sprint.
7. We then take 80, multiply it by 50% (determined in step 3), multiply that by the allocation for each team member (determined in step 2) and finally multiple that by 10 (the number of dedicated sprints determined in step 6).
The results is a top-down estimate of the number of hours each team member spent on the initiative.
There are a few assumptions here:
1. Teams are cross functional and work on a variety of things (this isn't exactly the case, but I think it works out).
2. Team members generally work the same amount (this can be tweaked with the % allocation of each member).
3. Everything that has story points should be cap'able work. So now, "research this" or "talk to this person" type of stories. Or if you have those, flag those as not-cap'pable.
The beauty of this is that I believe it gives a pretty good estimate of time spent without requiring hours tracking. It's also a fairly simple formula and a Scrum Master can churn it out in about an hour. I personally think it's about as accurate as a bottom-estimate hours estimate.
We're in the process of working with an auditor to see if this is legit, but our finance guys seem pretty happy with it.
If you'd like more information, or this is unclear, you can email me directly.
--- In email@example.com, "alisongilles" <alisongilles@...> wrote:
> Hello all,
> A somewhat random question, but our Finance team has instructed us to code all of our hours to one of the following categories: Analysis, Design, Build, Test, Post Launch Support.
> Obviously, this feels pretty non-agile. The response to questions on this has been that this coding follows Generally Acceptable Accounting Principles for capitalized/non-capitalized software development expenses, and that we don't have a lot of flexibility in this. Has anyone experienced this or is anyone familiar with the Accounting Principles for software?
- Good points, Mark. AsI said earlier, the accounting profession seems to be 20 years behind in its accounting practices and internal auditing practices for software development.
Date: Tue, 8 Dec 2009 22:46:31 +0000
Subject: [scrumdevelopment] Re: GAAP and Agile
R&D can not be capitalized, but once a product is deemed feasible, all design, development, and testing can be capitalized.
I have a stinking suspicion that your accountants have been led to believe that "analysis" is R&D, and not simply a high-level form of design.
Have you ever read the accounting rules for software development? It's clear that it was written by a group that was convinced that the waterfall model was the only viable one.
For example, software "maintenance" can not be capitalized, when in fact most "maintenance" is actually adding new features to software, which extends its useful life. Software does not break or wear out like a physical item. The same bits will continue to run indefinitely unless the environment changes. When it does change, modifying the software to run in the new environment *is* adding a new capability.
--- In scrumdevelopment@ yahoogroups. com, "extremeprogrammer" <LanceWalton@ ...> wrote:
> --- In scrumdevelopment@ yahoogroups. com, Ron Jeffries <ronjeffries@ > wrote:
> > Hello, extremeprogrammer. On Friday, December 4, 2009, at 2:24:49
> > PM, you wrote:
> > > Criminy! But can you really capitalize 'analysis' differently from
> > > 'design', for example?
> > When did a government or regulator ever care about that?
> That's what I was getting at. If the government and regulators don't care, then why do the accountants or finance department? If they can't use the discrimination between 'analysis', 'design', etc. to gain some tax break or something, then what do they do with the information?
Check out the latest features today Get more out of Hotmail