Agile Project Management: 3 Signs to Call It Quits

Even if you invest a lot of time and effort into a project, you may reach that very point when the further development becomes a waste of resources. So how can you tell when it’s time to stop an Agile development project and call it quits?

It definitely takes courage to stop a project when you still have user stories on the backlog. However, there are several practices that will help agile project managers make the right decision.

80/20 rule

This rule is based on the Pareto principle that says “20% of the input (time, resources, effort) accounts for 80% of the output (results). As far as the agile development is concerned, the first 80% of the requirements are implemented in 20% of the time. The remaining requirements will be implemented only after spending another 80% of the time.

In other words, in order to implement 20% of the remaining requirements, you will need 4X more time than you’ve spent to implement the first 80% of the requirements.

So the question is, will it be worthwhile to implement the remaining 20%? Give a serious consideration to this question and only then move forward.

The law of decreasing value

When you start a task, the generated value is always higher at the initial stage than at the final stage. This rule is called the law of decreasing value. The longer you work on a task, the less value it produces.

Watch your ideal “x” moment when the time/value ratio is optional. After the x-moment, the value will start to decrease, and it might be just the right time to stop this task.

A penny saved is a penny earned

It’s important to know how much every iteration costs. In this case, you will be able to explain to the product owner (or the business owner, stakeholders, etc) the cost of the remaining sprints. And if the value/cost ratio is not optional, you should decide if the sprint is worth running at all.

Conclusion

It’s obvious from all the above practices that it’s better to stop a project sooner than later. As soon as you notice that the value of a sprint is below acceptable levels, it’s time to call it quits.

The last but not least thing to remember is that it’s crucial for a project success to prioritize user stories in the right way. Otherwise, none of these practices will be used effectively.