Backlog Prioritization for Value Based Agile Software Engineering

A sprint burndown chart showing a partial sprint
Sprint burndown chart by tö, on Flickr. Used under a Creative Commons license, click image for details.

Have you ever wondered why earned-value management is not really about value but about cost? According to EVM, as defined for instance in the PMBoK, value=cost aka budgeted cost of work scheduled. The specific implementation of EVM used in e.g. Scrum is no different even if specific terms such as backlog and effort are used.

According to Boehm and Li this is caused by Software Engineering taking place in a “value-neutral setting”. Because there is a separation of concerns, implying that “IT” is only responsible for developing a solution to meet certain stated requirements cost – not value – will take a place of primacy and projects will “use earned-value systems to track project cost and schedule, but not stakeholder or business value”.

The answer to the cost-centric software engineering method is value based agile software engineering. If we knew the value of a particular feature or requirement and we knew or estimated the cost of implementing it we could easily calculate the effectiveness of implementing it and by prioritizing development in order of effectiveness we would maximize real ROI and hopefully reduce the time to market. In theory, this should be easy. Just ask the stakeholders to give a value to each requirement (which should be INVEST) then ask the developers to estimate the cost and divide (value/cost). In practice, it is not so easy.

References

  • [DOI] B. Boehm and L. G. Huang, “Value-based software engineering: a case study,” Computer, vol. 36, iss. 3, pp. 33-41, 2003.
    [Bibtex]
    @article{citeulike:3702946,
    abstract = {The information technology field's accelerating rate of change makes feedback control essential for organizations to sense, evaluate, and adapt to changing value propositions in their competitive marketplace. Although traditional project feedback control mechanisms can manage the development efficiency of stable projects in well-established value situations, they do little to address the project's actual value, and can lead to wasteful misuse of an organization's scarce resources. The value-based approach to software development integrates value considerations into current and emerging software engineering principles and practices, while developing an overall framework in which these techniques compatibly reinforce each other.},
    author = {Boehm, B. and Huang, Li G.},
    booktitle = {Computer},
    citeulike-article-id = {3702946},
    citeulike-linkout-0 = {http://dx.doi.org/10.1109/mc.2003.1185215},
    citeulike-linkout-1 = {http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1185215},
    doi = {10.1109/mc.2003.1185215},
    institution = {Comput. Sci. Dept., Univ. of Southern California, CA, USA},
    issn = {0018-9162},
    journal = {Computer},
    keywords = {20120103},
    month = mar,
    number = {3},
    pages = {33--41},
    posted-date = {2012-01-03 07:58:50},
    priority = {2},
    publisher = {IEEE},
    title = {Value-based software engineering: a case study},
    url = {http://dx.doi.org/10.1109/mc.2003.1185215},
    volume = {36},
    year = {2003}
    }

2 thoughts on “Backlog Prioritization for Value Based Agile Software Engineering”

  1. Earned value "earns" it's budget. That's all.

    Attributing other "values" to earned value creates a disconnect.
    The "value" in business units of measure of that "earned" budget can certainly be connected, but EV alone does not address the business value.

    That's the role of the business case, the capabilities based plan, or similar approaches to defining the business value of budget expenditures.

    Both EV as defined in ANSI-748B and "business value" measures are needed. EV provides visibility into the measures of physical percent complete and the utilization of that budget. The "business value" attribute measures that budget's contribution to the business. E.g. how does that budget expenditure earn it's keep.

    1. Thank you for your interesting comment!
      Because EV measures projected cost vs actual cost I guess we can say that there are two sources of variation here.
      - Projected cost can be wrong for various reasons.
      - Actual cost can vary for other reasons.
      EV would not in itself tell us how much each factor contributes?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>