Optimizing the success of an agile project
When is a good time to stop your agile project?
The goal of this article is to provide the reader with a range of tools, processes and practices in order to understand that a point exists in time, after which further development becomes a waste of time and resources.
When to stop an Agile development project and call it a day? When are the minimum number of requirements implemented to guarantee customer satisfaction within an optimal budget?
It definitely takes courage to stop a project when there are still user stories on the sprint backlog.
However, there are several theories and studies that support agile project managers in making the right decisions.
Here are a few that I find most interesting to consider …
80/20
Based on the Pareto principle, also referred to as “the 80/20 rule”, the first 80% of the requirements are implemented in 20% of the time. The remainder of the requirements will only be implemented after spending another 80% of the time.
In order to implement 100% of the requirements, you need to spend five times the amount of time needed to implement the first 80% of the requirements.
Will it be worthwhile to implement the remaining 20% ? Maybe, but it’s at least very wise to question this before moving forward….
The law of decreasing value
When you start working on a (development) task, the generated value will be higher during the initial phase of the development, than during the later phase. This is called the “law of decreasing value”. The longer you work on a task, the less value it cumulatively produces.
This is shown in the following graph:
‘x’ marks the ideal (theoretical) moment in time to stop this particular task as, up to this point, it provides the most optimal value/time ratio.
The Sprint Cost
Do you know how much a single iteration costs? You should…
This gives you a great tool to explain your product owner how much the remaining sprints will cost. This is extremely useful information if you compare this with the value of the user stories that these sprints will implement. After all, people like to think in terms of ‘euros’ and ‘dollars’ before they can understand the cost of a certain item.
If the product owner doesn’t care, maybe the business owner or stakeholder does…
If you plan to use this metric in your projects, you should communicate and apply it from the beginning. You need to agree from the start that the sprint cost is an important element to consider when determining the business value of a sprint.
The role of the Product Owner
It’s vital to the success of an agile project that the product owner prioritizes the user stories the right way: from high to low priority. It is the responsibility of the team to provide input and question the priority if necessary. Without a right order based on priority, all other theories and practices listed in this article can not be used effectively.
To summarize
All the above theories and practices show that you better stop a project sooner than later. As soon as the added economical value of a next sprint is below acceptable levels, it’s better to start wrapping up.
This is summarized in the graphic below:
As of sprint x+2, the value delivered by the sprint is not larger anymore than the sprint cost.
People should start wondering whether it makes sense to continue the project beyond this point, and whether starting sprint X+3 is still justified from an economical point of view.
The ratio V/C stands for Value/Cost. From a pure mathematical point of view this ratio should ideally be >1, as this means that the sprint produces more value than its cost.
In a future post, I will write about how to determine the V/C ratio. In other words, how to define the economical value of a requirement.
Stefan Luyten
For more information: http://www.triton-consulting.be
