Re: [!! SPAM] RE: [scrumdevelopment] Re: GAAP and Agile
- This is really nice, and easy to understand and implement. Let us all
know how it goes, and make sure to write it up somewhere...
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
Cheng, Richard wrote:
> Hello Max, I really like this idea! Tracking of capitalizable work was
> really one of the last true barriers in regards to removing hours out
> of the planning process altogether. Please let us know what the
> auditors say.
> Also let the gang know I said Hello!
> Richard K Cheng, PMP, CSM, CSP
> Managing Consultant
> Excella Consulting
> richard.cheng@... <mailto:richard.cheng@...>
> http://www.Excella.com/ <http://www.excella.com/>
> *From:* firstname.lastname@example.org
> [mailto:email@example.com] *On Behalf Of *maxwell_keeler
> *Sent:* Wednesday, December 02, 2009 1:26 PM
> *To:* firstname.lastname@example.org
> *Subject:* [scrumdevelopment] Re: GAAP and Agile
> 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
> 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
> 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
- 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