What is the standard unit of measure for software development?

Home Forums Program and Project Management What is the standard unit of measure for software development?

This topic contains 6 replies, has 5 voices, and was last updated by  Josh Nankivel 6 years, 7 months ago.

  • Author
  • #154275

    Travis K. Anderson

    Estimation Measures

    • the construction of a new home uses square feet
    • instructional system design uses instructor led lecture hours

    What is the standard unit of measure for software development?

    I am a bean counter looking for a way to extract a means to measure the performance of a gov’t software development project during the implementation, test, and integration phases. It is my hope to convert from “Effort Orientated” to “Success Orientated” units of measure for capturing earned value.

    Should I use requirements, testable requirements, features, function points, requirements verified, etc….

    Any links, references, and advice would be appreciated.

  • #154287

    Josh Nankivel

    Function points are a decent way to go, but there’s a level of maturity you need to build an organization up to before being ready for that I think. Resource: http://www.dpo.it/resources/papers/1999-fesma-fpestmet-en.pdf

    Personally my teams and I generally start with planning poker on our teams’ deliverable features/functionality. These may be in the form of user stories too, but I haven’t been successful at doing it with user stories within a waterfall project. There are too many cultural differences and it’s too hard to translate the lean/agile language back up into waterfall-speak.

    With planning poker, it’s decks of cards with the Fibbonacci sequence. Mine are from Mountain Goat Software, and are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. Because we are working in a waterfall world, we’ve defaulted back to using hour estimates because again, it was just too much work to try and translate these two different world views.

    If I could do it any way I wanted, I’d start with user stories and use planning poker for estimating relative story points with the team, and just use the team’s velocity to project completion dates. We wouldn’t ever think in terms of hours of effort or duration, only in terms of story points and velocity.

  • #154285

    Bill Brantley

    This is a good classic blog posting on the topic – http://martinfowler.com/bliki/CannotMeasureProductivity.html

    Having said that, I think your best approach is develop a measure based on features delivered. The whole point of software development is to create an application that does something whether it be word processing or creating spreadsheets. Thus, a measure based on how well the software development fulfills the customer’s needs would seem the best way to measure productivity.

  • #154283

    Josh Nankivel

    I like that post Bill, hadn’t seen that one before.

    I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It’s really just as valid a measure as any other arena like construction…you have assumptions that requirements were elicited properly and you are actually building what the customer wants.

  • #154281

    Travis K. Anderson

    Thanks Josh and Bill. Great comments and reference links. I will dig in and continue to experiment with my software leads in developing best approached for encompassing earned value.

  • #154279

    Mihail Sadeanu
  • #154277

    Chris Cairns

    If you are employing agile software development methodologies, there are emerging techniques (e.g., business velocity) for measuring success / value delivered at any point during the project.

    There are even some whitepapers floating around on how to apply EVM to agile software dev projects. For ex: http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf.

    Dig around a bit and see what you come up with. Happy to elaborate more on points above, if need be.

You must be logged in to reply to this topic.