Loading ...
Sorry, an error occurred while loading the content.

11381Re: [scrumdevelopment] Re: Project Capitalization

Expand Messages
  • mpkirby@frontiernet.net
    Feb 1, 2006
    • 0 Attachment
      On 1 Feb 2006 at 7:19, pborsella wrote:

      > --- In scrumdevelopment@yahoogroups.com, "aliciayanik0724"
      > <aliciayanik0724@y...> wrote:
      > >
      > > I'm sure this has been asked and answered before, but a quick search
      > > didn't turn up enough information for me. I'm looking to understand
      > > how other organizations, while using Scrum, gather the data
      > necessary
      > > to capitalize projects (and pass an audit).

      Are you referring to the financial requirements to determine whether development expense is
      considered an R&D line-item, or a SAG line-item? (where R&D items can be capitalized up
      until product launch, and SAG items must be expensed.)

      As I understand the rule, if you are developing a new product, or a major upgrade that
      customers must pay for, it is considered R&D. Maintenance releases, or feature releases
      that are covered under existing service contracts are considered SAG.

      At least that was how it was explained to me.

      What we do is allocate a budget of "stories" to each of the product programs. THe stories
      are prioritized into a single backlog, but we are mindful of the budgets. So the "continuing
      engineering" budget for a past program (That might coutn against SAG) may only be 1000
      story hours. But the new product might be 1500. So during the upcoming release (which
      might have different end dates), we make sure to prioritize 1000 story hours worth of stories,
      but no more for the older product.

      We track against stories as well, but by and large don't close the financial reporting loop.
      Aparently the "budget spent" is more important then the "how it's actually spent", but they
      tend to be reasonably close.

      The obvious "scrum" flaw in this approach is that it's possible to deliver a low proiority feature
      for a product above a high priority feature for another product whose budget is exhausted. I
      think the real answer is to tie the budgetting to tracking, and prioritize between programs, but
      that's very difficult to do in the large corporate environment.


    • Show all 5 messages in this topic