How to balance business and technology requirements in a product backlog to build a successful product in long term.
Product ownership is hard stuff. Very often you feel 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 of different requirements types.
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 the implementation of business requirements. Of course, there are direct earnings connected to them. So the idea to get cash fast and often is not mindful.
Real-life experience, however, shows the following weaknesses in long-term:
- The product changes take a longer time to implement because of the increasing complexity of the product.
- Team members have more and more problems estimating work.
- The estimation is absolutely not correct when compared to reality.
- New requirements ask for competitive functionality that can’t be achieved with the current way the product is implemented.
- The cost of product operation and maintenance is increasing. In a 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 the unavailability of such versions.
- Due to that, agile teams have to develop uninteresting things. This is very often the main reason why they leave a company. Not because of salary, not because of people.
- A technology blocks faster delivery.
- 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 from a long-term perspective significantly. The business people in most cases are aware of 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 staff must be leveled. Even they have to build by non-product ownership roles (i.e. architect), the product owner is accountable for ordering and proper mixing.
While building up the ScrumDesk, Scrum Project and 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 of 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 a much longer period of time. Benefits are barely visible. As the 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 product development. Every sprint, I as the product owner, decide which technology debts will be solved. I try to invest 20-30% of an effort into it.
ScrumDesk project management tool provides the possibility to set requirement type, color, and even definition of done for technical requirements. Further analysis can be done with Microsoft Excel. where data can be exported to.
The DevOps team suggests topics in release plannings and in every sprint pre-planning session. 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 the 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 it. For example, in the case of the performance, we set up performance goals that 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 our decision-making process in upcoming sprints much better. Simply, I need to know the portion of the 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 others more on debts. But both parts are included in all sprints.
Conclusion
Our approach is beneficial for everybody involved in 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 piece of advice left. Go for it!
