Agile focuses on delivering the highest business value to the interested parts of a project.
However, (at least in my scenario) it seems that the client/stakeholders are always focused on having more and better features, while avoiding to even glance to technical gaps and performance improvements (except when they become too obvious, or the problem is already too big to be easily fixed).

How could the PO (or the development team) show to the people in charge the business value of these needs, considering that to do them it will take some time from the features-development resources?

9 Answers 9


Schedule a meeting with them to talk about the technical debt and the development process in general. Create an interesting presentation with images and figures to support you. Cover the following topics:

  • the 'invisible' part of development. Not all dev activities result in a customer-facing feature. There is backend stuff, refactoring, research, maintenance. Give few examples from your project.

  • if you work iteratively, explain that the first version(s) although already implemented and tangible, require further bugfixing and 'invisible' work, otherwise the feature may not be stable enough to be used in the real world. Again, show examples and list the reals risks of avoiding this work. E.g. 'The number of sign-ups will decrease by 7.5% because we have a critical bug in FireFox. 15% of our visitors use FireFox and we have 50% conversion rate'

  • the concept of technical debt as 'Implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer'. That it's a common part of each project and that there will always be some debt, but it's also a common practice to reduce this debt. It's important to outline here the risks for the business side. 'Code will be hard to support' won't convince, but 'The budget to add the list of the latest user's activities to the Dashboard will increase by 200% if we don't refactor the user's module right now' may.


There are two parts to this depending on what you mean by technical gaps.

First, is building the feature right. Any feature should have enough time given to be built in the technical constraints of the system. Because each increment should be a shippable product (I'm leveraging a Scrum assumption here), that means that for a feature to be done, it must meet the technical standard for a finished product. This means fully tested, performing at an appropriate level, maintainable, etc.

There are exceptions - for example you could build out a version of a feature for a select beta group to use knowing there are performance changes needed to roll it out to everyone, but this should be the odd case where the payoff in knowledge value is worth it and it's the least wasteful way to approach the problem.

There are a number of agile practices that support this. Definition of Done helps the team push back against pressure to cut corners. BDD and TDD both build refactoring into every development cycle to spread it out and make time for it instead of letting it pile up.

The second part is features that have no apparent business value because when they are done right, the user can't see them. The trick here is that they have incredibly high business value, the team and PO just need to learn how to express it. The example I always give is that I would have loved to see more security stories on Experian's backlog. Another example may be that the current architecture won't scale and with your current growth numbers the system will become noticeably slow in the next 6 months. It'll take you 3 months to refactor the underlying architecture, so you better start soon. See, lots of business value - you just need to express it. You also need a strong PO for this with the authority to set direction.


This kind of "invisible", non-user-facing, "infrastructure" work reduces the cost of future work (eg, spend time now making code more maintainable so that spiffy feature you're going to ask for in 6 months will cost less to implement) and reduces risk (eg, if you don't keep the infrastructure up to date, including updates for compatibility with new versions of libraries, you run the risk that some critical security fix is going to come out but you'll be 5 versions behind and it will take weeks to upgrade).


Two things spring to mind about your question.

Firstly, the Product Owner is the person responsible for the product. They prioritise requirements and work closely with the development team to understand the technical solution (quality, non-functional requirements, etc.). Of course the Product Owner will listen to the opinions of stakeholders, but it is they that make the final decision.

This is one of the great strengths of Scrum. It means that decisions on the backlog are taken by somebody who spends a great deal of time with the development team and gets what is really going on. It is much easier to convince the Product Owner of a technical requirement than to convince a stakeholder who has limited exposure to the team.

Secondly, agile depends on trust. The development team trusts the Product Owner to make the right decisions about backlog priorities and the Product Owner trusts the development team to make the right decisions about delivery.

Personally, my preferred way to work is to wrap all technical requirements in to user stories. For example, if the development team recognises that they need to do some re-architecting to improve performance then they would wrap that into the delivery of a business feature. Of course this means that the amount of work necessary to deliver the business feature is a lot more than some people will expect. But as the Product Owner works so closely with the team they understand why this is being done.

Note: I'm assuming you are using Scrum as you mention the Product Owner role, even though you haven't used the Scrum label.


It is hard to have a meaningful conversation in a vacuum.

Begin reporting Key Performance Indicators (KPIs) that show the time and money spent as a result of non-strategic infrastructure. It is best if these are concrete, objective metrics pulled automatically from your operations systems. If statistics of this sort are not easily discoverable, a custom analysis may be required or you may need to begin capturing additional information. Some examples:

  • Tech debt related incidents / total incidents
  • Tech debt related defects / total defects
  • Planned task effort assuming strategic infrastructure / current infrastructure
  • Monthly waste associated with non-strategic infrastructure in dollars
  • Tech debt velocity penalty
  • Code churn attributable to tech debt / total code churn

In addition, A risk analysis on potential failures resulting from your technical debt could cause unplanned expenses. Indicate the cost should a failure occur along with an estimate of likelihood of such a failure.

A third potential consideration is the integrity of the technology team. Morale of the team may be adversely affected by excessive maintenance activities and/or antiquated technologies. The cost and likelihood of a leaver associated with irritant can be presented as a risk above. In my experience, most stakeholders are not greatly affected by this line of argument.

When you have the data to make your case, then you can begin building consensus within the stakeholder community by attacking each individual stakeholder's specific concerns be it cost, delivery timetable, reliability, or whatever one by one. In an individual conversation, you can find which points land and which fail to make your argument stronger for the next stakehoder. When you've built up critical mass among the staeholder community, then have the prioritization meeting to divide activities between functional and debt-servicing.

If you can't convince stakeholders using data, you should at least consider the possibility that they are right. Potential performance or reliability improvements may not be justified by the cost required to fix them. On the other hand, a Product Owner has the responsibility to prioritize re-engineering if warranted. A PO that feels strongly enough has got to do it even without buy-in.


The best way to convince individuals is speaking their own language. In this case, building a business case around the importance of technical needs.

Show them clear numbers of the actual cost. Some examples:

  • Hosting. When I was tasked to analyse the systems of a company, they literally reduced 10 times their hosting bill after some "simple" changes that improved performance.

  • Development workforce. Tasks in well structured systems take a lot less, literally 2-3 times less. Also as the system grows, the complexity that it can take to develop something grows exponentially.

  • From the previous point, it's inferred that they are actually going at 1/3 of the pace that they could do if they had a well structured software, and they seem to love to go fast :)
  • On-boarding new developers / The cost of loosing one. Filling developer position will be very complicated. In fact, good developers might question wether it makes sense to join a company who didn't care about technicalities.

My suggestions to your challenge are:


If you have a client who is focussed on "features" and "functions", try to shift the conversation towards "outcomes" and "capabilities". It's a subtle shift, they may not even notice it, but it will help you considerably.


Technical debt is a concept invented to communicate the size and implication of known quality shortcuts that have been taken. Again you can focus on the words "quality" and "risk". Technical debt usually means risk of functionality not working as intended, or some non-functional risk, like cost to maintain, poor security or poor performance.

Change the language you use and you can more readily guide the outcome.


That depends on either the product you're working at is assumed to have long or shord lifespan. Since it is clearly a problem of technical debt.

As any debt has its cost to be addressed and each new "release" that cost grows up, the stakeholders (those ones who control budgeting) are interested in keeping the long-term budget in originally estimated bounds (they are actually interested in short-term budget predictability as well, however the latter is much easier to achieve).

I would use the planning to demonstrate over time that new code integration into the existing code base costs more that it would having the existing code more well-designed, well-structured and well-developed in general.

If your debt is big enough, then the costs growth should start looking representative in a few months so that the technical aspects become more sensible to business-oriented people.


I recommend learning about Six Sigma

It seeks to improve the quality of the output of a process by identifying and removing the causes of defects and minimizing variability in manufacturing and business processes. It uses a set of quality management methods, mainly empirical, statistical methods, and creates a special infrastructure of people within the organization who are experts in these methods. Each Six Sigma project carried out within an organization follows a defined sequence of steps and has specific value targets, for example: reduce process cycle time, reduce pollution, reduce costs, increase customer satisfaction, and increase profits.

To put it more plainly. There are several methods identified by the Six Sigma process that allow you to project cost savings through process improvement, and then track the actual savings.

When I was doing this for a Major Manufacturer based in Central Illinois, we often found that we could project savings that were so great, that management would not believe the potential. We several times had to sharply reduce our projections, not because they were wrong just because they we too big. But the actual savings would many time bear out our projections.

The first step(yellow belt) is usually a 2-3 hour class followed by applied learning through participation in a real world project.

The second step(green belt) is usually 8-16 hours of classroom plus applied learning through leading a project under the supervision of a trained leader.

The third step(black belt) usually consists of approximately 2-3 weeks of intensive training, followed up by applying the knowledge in projects, and regular continuing education, as well as supervision of green, and yellow belt projects.

The final step(master black belt) varies by business, but mostly consists of managing the Six Sigma Process, for the business, and mentoring other members on Six Sigma, including performing training for the lower level steps.

I am explaining the steps because there are literally volumes of information that would be required to answer this question more directly

  • I am going to assume down vote means you do not agree with the idea of learning six sigma unless I hear otherwise.
    – Chad
    Apr 9, 2018 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.