How to balance business and technology requirements in a product backlog to build a successful product in long-term.
A product ownership is hard stuff. Very often you feel a schizophrenia. Often you play for a customer, but later, suddenly, you have to protect your team. Sometimes you are pushed by the business, later by architects and the development team. There is a knowledge transfer necessary, research requirements, operational, supportive tasks.
It is the product owner who should introduce an order into all that mess.
But how? Well, as it is usual in Agile, there is not just one correct answer.
Why level business and technology
Companies are pushing hard for an implementation of business requirements. Of course, there are direct earnings connected to them. So the idea to get cash fast and often is not mindfulness.
Real life experience, however, shows following weaknesses in long-term:
- The product changes takes longer time to implement because of an increasing complexity of the product.
- Team members have more and more problems to estimate work.
- The estimation is absolutely not correct when compared to the reality.
- New requirements ask for competitive functionality that can’t be achieved with the current way the product is implemented.
- A cost of product operation and maintenance is increasing. In few cases constantly, more often exponentially.
- It is more difficult to hire new team members due to uninteresting technology.
- The cost of the development can’t be lowered with help of publicly available libraries or new technologies due to an unavailability of such versions.
- Due to that, agile teams have to develop uninteresting things. This is very often main reason why they leave a company. Not because of salary, not because of people.
- A technology blocks faster delivery.
- An automation of tests and deployment is not possible due to the technology.
- A performance is decreasing and it is very expensive to improve it.
The business must understand these impacts as they influence the business in long term perspective significantly. The business people in most cases are aware about that, but they don’t see the way how to solve those issues.
Hey Product owner, level the backlog
For the success of the product, the product backlog must contain requirements of multiple types. The product owner must have ‘two+ legs’. The business, technology, performance, research, operational stuff must be levelled. Even they have to built by non-product ownership roles (i.e. architect), the product owner is accountable for an ordering and proper mixing.
While building up the ScrumDesk, scrum project management and agile product management tool, we tried multiple approaches how to deal with technology debts.
The best approach we found is simple. To have our sprints ‘multicolored’.
Approach A: Technology sprint
When you start to develop a new product, you are keen to give customers necessary/unique functionality ASAP. As the product is more successful, there are more users and performance decreases. The product is internally more complex and it is not easy to change the architecture to be more flexible and faster.
Many agile teams solve that with sprints focused on technology only. Technology sprints, tech debts sprints, innovation sprints, etc.
Business is not satisfied with this. They get 0 from a business perspective regardless how much you explain how such investment will bring money later. In reality, it must be admitted the business is absolutely right.
It is not the business who will not earn money. It is all of us.
Such planning is therefore not suggested. The debt is solved in small steps and in much longer period of time. Benefits are barely visible. As duration between such sprints is often 3-4 sprints, the team will even forget what they developed before.
This way of planning is valuable only if you have to do complex refactoring or full change of the architecture. Simply to say, to restart the product development.
Approach B: Small pieces every sprint
This is our preference in ScrumDesk which we found the most valuable in 10 years of the product development. Every sprint, me as the product owner, decides which technology debts will be solved. I try to invest 20-30% of an effort into it.
The DevOps team suggests topics in release plannings and in every sprint pre-planning sessions. No items are added suddenly into the current sprint. Tech debts fixes are always planned.
They have to bring business impact/value for every item. It is not just We want to play a little bit with tex!
Sometimes is such value cost savings in hosting, or support, or just operational performance and load. Sometimes it is about an extensibility and flexibility of the development of future features. As we have the roadmap, we know what makes sense.
Then the team estimates and breaks requirements into smaller pieces so they can finish the most important part of them in the next sprint.
One part of our agreement is to prove that investment was worth. For example, in case of the performance, we set up performance goals which have to be achieved. It was challenging, but our team achieved much more than expected. That was a big motivator.
At the end of the sprint, I always try to evaluate how much effort we invested into tech debt so we can improve or decision-making process in upcoming sprints much better. Simply, I need to know the portion of budget is necessary on average in sprints.
Based on the results we decide the percentage split. It is not equal in all sprints. Some sprints are more focused on the business, some other more on debts. But both parts are included in all sprints.
Our approach is beneficial for everybody involved in the product development, sales, delivery, and operation.
All parts are satisfied to some extent in every sprint. They are not forgotten. They can prioritize the next thing easily.
Developers can use new technologies as well. We try to convert them into the business ASAP as they often bring additional savings and competitive advantages.
So there is only one advice left. Go for it!