Browse Prior Art Database

Quantifying the Benefit of Feedbacks of Agile Software Development

IP.com Disclosure Number: IPCOM000195127D
Publication Date: 2010-Apr-21
Document File: 2 page(s) / 30K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article formalizes the feedback from Agile Software development by quantifying the improvement that may be attained from the feedback. The quantification of the feedback enhances its quality by discerning which feedback is worth implementing and which is not; in order to increase the rate of return on the Software development investment.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Quantifying the Benefit of Feedbacks of Agile Software Development

Agile Software development methodology calls for continuous feedback from the Stakeholders and the development team. Normally, this is done by the end of each Sprint which is usually around 4 weeks in length. During the Sprint review, in addition to the product demo and Stakeholders feedback, the team discusses the lessons learned, what worked and what did not work. Applying what is learned from the Sprint feedback provides for a continuous improvement to the process by maximizing the opportunities and minimizing the constraints through improved techniques and therefore improving the productivity of the team and the rate of return on investment. The Sprint feedback formalizes the process of continuos improvement. Given the small amount of time required for this feedback, the improved productivity and rate of return is considerable, no matter how little the improvement is.

While this feedback benefit is apparent and can be described, it cannot be readily quantified; because some of the feedback may be material and some feedback may simply improve the morale of the team. It is useful to formalize this feedback; in order to improve it and answer the question of how much feedback is needed and at what point additional feedback become useless overwhelming or monotonous. This disclosure formalizes the Agile feedback process by quantifying the improvement from the feedback.

The ROI described in " Agile Management For Software Engineering Applying the Theory of Constraint for Business results " [*] as follows:
ROI pre-investment = (Throughput (T) - Operating Expense (OE) ) / investment (I)

Assuming the feedback calls for additional delta investment the ROI equation becomes ROI post-investment = ( (Throughput (T) + delta Throughput (dt)) - Operating Expense (OE) ) / (investment (I) + delta Investment (dI)

To simplify, the equation can be written

ROI post-investment = (( T + dt ) - OE )/ (I + dI)

Now assuming the Operating Expense are fixed and handled by the organization and not by the project itself, the function at that time may be reduced to:
ROI post-investment = (T + dt ) )/ (I + dI)

The ROI post-investment should be greater than ROI pre-investment dt > dl, the greater the dt relative to dl the

better.

How ROI investment apply to the feedback in Agile.

Depending on the feedback the delta investment could be just the time spent on the feedback and therefore very minimal(even negligible), however the delta throughput can be relatively considerable specially if the feedback just calls for process improvement, a different way to conduct business without additional expenditure of resources ( money, time or additional developers ).

There is benefit in spending few hours in the feedback, whether saving in time, saving in

1

Page 2 of 2

money or saving in personnel. The additional return of inve...