by Bas VoddeIt is easy to build a product. It is hard to build a lasting and maintainable product. To build a sustainable, healthy product development organisation, it is key to understand the types of work that are going on and find the appropriate balance.
For the last four years, the Wärtsilä Holistic Agreements Lifecycle Ecosystem product has been working in a LeSS structure. As a part of that, we’ve been experimenting with increasing the transparency of what we work on for ourselves but also for the rest of the organisation. A precondition for creating more transparency was a good one Product Backlog (with 10 teams working on it), properly structured and containing everything the teams do. In product development, teams do not only work on new customer functionality. We wanted that to be visible on the Product Backlog and throughout the organisation. We created a work categorisation to reflect this.
Note: The naming of the work categorisation reflects the industry that we work in to make it easier to explain throughout the organisation.
In today’s deadline-driven, AI-generated world, it is easy to create small products, prototypes and demos that make customers and managers wow. But building a larger, reliable, maintainable system is hard and is a lot of work. Many larger systems started out as smaller ones, or combinations of smaller ones, and then much work goes into fixing things that were done in the past. At the time, these seemed reasonable decisions, but with the additional knowledge of today, they often seem like mistakes.
Understanding the work being done is key for understanding and managing large product development. Two dimensions are particularly interesting:
These two dimensions are shown in Figure 1.
Sustainable product development is not about just building more features. It involves a variety of work and understanding the types of work in product development is important to find the right balance for a healthy product.
The categories we use are:
Typical activities: Bug fixes, outages, missing data
One line summary:
If this work is not done, the product isn’t functioning properly.
Something has gone wrong. Mistakes were made. They need to be fixed. Much of this work is preventable by improving our ways of working. Deadline pressure and low quality standards (e.g. low-level of test automation) is usually the cause of this work.
It can’t be completely prevented but continuous work is needed to keep this as low as possible.
Typical activities: Upgrades, resize, reconfigurations, cleanup, some rewrites due to EOL
One line summary:
If this work is not done, the product will stop working in the future.
Nothing has gone wrong yet but things in the operating environment have changed. If we do not respond to this then this might lead to downtime or a security risk.
If this work is not done regularly, it will pile up and cause more work. It can’t be completely prevented but the risk and effort can be reduced through monitoring and automation.
Typical activities: Automation, alignment and standardization, rewriting or refactoring
One line summary:
If this work is done, the product development improves and the other maintenance activities are reduced.
The other maintenance types are gradually reduced through proactive maintenance activities. Proactive maintenance work also improves developer experience, increases efficiency, and improves capability of the development and infrastructure.
This work is an investment in reduction of cost, effort, and increase in internal quality and reliability. However, it will never end as changes in environment, evolution in technology and feature development activities will create new improvement opportunities.
Typical activities: Monitoring, responding to queries, activation, manual release activities (dev/acc/prod)
One line summary:
If this work is not done, we don’t know whether the product works.
The product is in production, is used, and needs to be kept up. Monitoring the status of the system in production and responding to queries from different users are continuous activities. At times, new activations and configurations need to be done.
This work is continuous and much of it can be reduced through proactive maintenance by improving the product and automation.
Typical activities: Feasibility studies, user research
One line summary:
These generate insights and might lead to new items or changes in priority.
Not all work in product development is direct development activities. Sometimes time needs to be taken to investigate a potential direction of the product or to learn more about customers and their problems.
Typical activities: Small feature requests directly from users or large features on the roadmap
New features improve the product’s purpose and use. Ideally, this would be the majority of the work, in practice, the other types of work take a significant amount of time.
Every product should have a business case and a roadmap of desired features and improvements. This is used to determine the amount of investment an organisation wants to make — in large organisations, this is typically expressed as a budget. However, when a product is in production and being used, then this will trigger emerging work that is often smaller yet important. These emergent items could be smaller features but it often is work to ensure the product keeps up and running and improving.
Thus one dimension of work is:
Roadmap items — Bigger items that are on the roadmap. Many of these are new features but they may also include longer term improvements that will reduce maintenance effort or operating cost. Roadmap items are usually split into smaller items before they get selected in a Sprint.
Emerging items — Smaller items that are not linked to the roadmap that also need to be done. Some of these are customer-facing such as responding on feedback or making small product improvements. But a significant portion of the emerging items is fixing things or improving things. Every product will have emerging work.
Sometimes all of this emerging work is categorised as ‘maintenance.’ Maintenance is then a black box and the only visible part of it is bugs. Labelling all emergent work as maintenance gives a wrong impression as some of this work is caused by mistakes and some of this work is improvements in the product. Ensuring a healthy balance between these types of work leads to a better product and more efficient product development.
The two dimensions — type of work, and planned vs emerging — combine to give a fuller picture of where effort is going:
| Type of work | Roadmap | Emerging |
|---|---|---|
| Reactive maintenance (Bugs) |
Reactive maintenance might happen in roadmap items due to continuous delivery | Typical bugs |
| Preventive maintenance (Upgrades) |
Replacement of EOL technology or large upgrades | Updating versions of dependencies |
| Proactive maintenance (Internal improvement) |
Larger often architectural improvements | Small improvements coming from teams |
| Operational (Monitoring) |
Not common | Monitoring or manual releasing |
| Investigation (Research) |
Significant research or new direction of product | Technology studies or customer visits |
| Product enhancements (Features) |
Desired roadmap based on business case | Small feature requests |
A good mix of these items is important for healthy product development. In a LeSS context, the Product Owner can use these types of work for prioritising the work for a Sprint to ensure there is a right balance. Some tips:
At Wärtsilä, mapping our Product Backlog to these categories was an eye-opener.
Only prioritising or managing (on the Product Backlog) new features will lead to a lack of visibility and unhealthy, unsustainable product development. To avoid that, creating full visibility of different types of product development work is the key to prioritisation and analysis. These should be the basis of your Product Backlog and work reporting towards the development and the rest of the organisation so that everyone understands the current situation and manages based on the current reality.
Try categorising your current backlog. The result might surprise you.
RSS feed