Simple Economics of Agile Planning

Professor Philippe Kruchten, in his teaching, describes what is to me the most brilliant explanation of simple economics of agile planning I've ever run onto. If you haven't had a chance to listen to him speak I strongly suggest doing so.

I'll try to briefly go over the principles, trying not to do him injustice too much.

The Four Elements

Professor Kruchten starts from a simple postulate that everything in agile can be explained with four categories of work (hence my analogy to four elements of nature):

1. Feature
2. Issue
3. Architecture/Infrastructure
4. Technical Dept

A feature is the type of work that provides customer value in the sense of delivering new functionality. A feature is something that the technical product manager would define, based on interviews with clients and other stakeholders. It is arguably the most important type of task.

An issue is something that is introduced during development and represents a failure in the delivered functionality that needs to be corrected.

Architecture/infrastructure type of work typically represents core framework or plumbing improvements, not directly visible to the customer, but still in support of the features driving the agile project.

Technical debt, probably the most neglected type of work in agile, represents the work that needs to be done in order to fix all the problems caused by taking shortcuts in technical design that prevent us from implementing the features.

Value vs. Cost

So far we have established a base framework for observing the metrics of the agile project without really looking at any measures.

The key measures that come into play are value and cost.

Cost is a little easier to define. Cost represents the measure of how much effort is required to complete a particular task.

Value, on the other hand, is significantly trickier to define. How we determine the value depends on the type of task we're considering. A feature-type task has positive value and that value is typically determined by how much value a certain feature delivers to the customer. It can often be measured very precisely, considering the indirect gains a feature may produce for the customer, such as monetary gain, strategic gain etc. An issue is said to have negative value. Delivering an issue lowers the value of the delivered features. Again, it can be measured similarly to feature value, but in terms of how much it indirectly prevents some gain. Architecture/infrastructure tasks also have value, but that value is typically driven by the value of the features they enable. Often these types of tasks are required by technical and non-technical requirements and therefore cannot be avoided.

The value of technical debt I find most interesting of all. We already said that technical debt is caused by taking shortcuts in technical design, delivering features without building out the right frameworks in support of extensibility and flexibility and thus making it harder to add new value down the road. This is why it is referred to as debt. By taking shortcuts we prevent some future work and we need to pay it back before we can deliver that future value. But it has another interesting characteristic: it grows with interest, another thing that makes it similar to financial debt. The reason it grows is because the more features we implement on the legacy architecture the harder it is to refactor, therefore the more cost it will take to pay off. Therefore it's cost grows over time.

Features, on the other hand, can depreciate in value over time. Postponing a feature for a later release cycle may lower it's value to the customer. This is where we see the dynamic nature of simple agile economics. Value in the backlog can change, existing tasks can depreciate, new value can be added, while at the same time cost can change as well, cost of technical debt will grow.

The Art of Planning

Given what we said so far about the model of economics of agile projects, how does one approach agile planning? Typically from the value/cost perspective.

In each sprint you have a certain amount of time and resources (people, really). The goal is to fit as much value as possible in that box, while making sure the cost can fit. This is where you need to find the right balance between all four types of tasks, making sure to balance out the needs of stakeholders such as technical product managers, support, developers and architects. Each group will try to inflate the value of the tasks they see as having high importance, so being realistic and determining the true value of each task is key.

Another very important thing is keep an eye on the future, don't just focus on the current sprint. Delivering less value in the current sprint while trading it off for paying back some technical debt, may enable the delivery or far more value in the next couple of sprints therefore maximizing the total value delivered over several sprints.

That's it. It's as simple as that!