Feature requests, bug fixes, and tech debt retirement. There are all ‘requirements’ from the technical team’s perspective because they incur effort, need testing, and someone will be unhappy if it goes wrong. It is the same for data modifications, regulatory changes, software upgrades, and platform patching.
Disagree? That’s cool. Simply tell your developers the next production bug is a ‘zero effort task that doesn’t need testing, has no stakeholder but should be fixed immediately’.
Feature requests, bug fixes, tech debt retirement, data modifications, regulatory changes, software upgrades, and platform patching.
Every one of these ‘requirements’ belong on the backlog, because by not doing so, you prevent planning from having a clear view of everything that needs to be done. The art of product management is judiciously considering the priority, dependencies, and effort of each item, and scheduling them accordingly. You can’t do this without a single consolidated backlog.
Every well-functioning team will be only too familiar with this juggling act, and many of these teams won’t even have a ‘product manager’. Business, technology, operations, compliance etc, advocating their own needs and working together is what’s going on here.
Conversely, if you’ve only got a business analyst focused on user stories and no technical leadership, or a strong technical leader with little business interaction, then you’ve got certain trouble. The most obvious signs are last-minute requests, firefighting, context switching, unhappy users and unhappy business stakeholders. Each product release is a ‘brace yourself’ event.
The solution is planning across all moving parts of the product, and this requires having a single consolidated backlog; something fairly straightforward to produce, if you know how.
If your developers are struggling, perhaps they need better guidance?
Our Software Requirements can help with that.