Scrum is great at getting an organisation to prioritise. The Product Owner is responsible but clearly they need to get some level of buy in from other stakeholders a bit as well. Having a prioritised backlog is a key component for successful Scrum. It allows the team to focus on the real business needs of the organisation. This is awesome.
But when we start to aggressively question ROI on every single change that we make we often deprioritise work that actually does need doing. Work that is more intangible often doesn’t get done. Work that is low priority but provides the polish that is necessary to be truly proud of the work doesn’t get done. Often these are the bugs that can be argued as features that really should be killed – but they never are and hence hang around – for good reason. They actually are things that we missed or things that we could tweak that would make the solution a more professional one. But because the current priority is The Next New Epic they don’t stack up in the prioritised backlog. So they go unattended.
Why have you still not done this obvious stuff?
This generally goes on for a while and then a stakeholder gets irritated and asks why these issues are still not fixed. The answer is simple – they haven’t got to the top of the backlog priority. And then the interesting discussions start coming out.
Now we’re thinking
Suggestions arise such as – let the team take in say 15% of their time as low priority items that had been around for a while. Or, let one person work on low priority items each sprint. These suggestions are great as they show a commitment to getting some of this work that should be being done, done. Perhaps the PO should have been prioritising a bit more.
- 15%? That is difficult to actually quantify isn’t it? Unless we count it in number of days. And it rather defeats the point of the blackbox of the sprint.
- 1 person planned with known assigned work during a sprint? That impacts the rest of the team as it will need testing and deploying and potentially interact with their planned work.
These don’t feel like collective ownership solutions.
I’ve seen different scenarios play out in solving this – some more team oriented than others
- X% time – essentially reduce the velocity to give time for picking up the low priority work
- Fixed chunk per sprint – take Y stories / X points in the sprint
- Give it to the support guy – if you have a rotating support person on your team – either they do support or they do low priority work when there is none.
- Give it to the support team – if your organisation has multiple teams and one rotates onto support – let that team pick up these items.
- Do dedicated sprints for low priority items.
- Just prioritise it like backlog always is prioritised.
I’d much rather see the PO plan the work. Potentially with the team taking 1 story per sprint to deal with it. Maybe put it at the end of the sprint’s backlog so that if anything falls out of the sprint, this work does. Then at least they can plan and prioritise it and work collectively. And share the responsibility of getting the work done. Kind of like Scrum intends!
I personally prefer the approach of incrementally dealing with a bucket load of work. For things like technical debt (which some of this may be) or low priority work or minor/trivial bugs – I’d rather see a product owner prioritising a small number of these into every sprint so that the product is continuously being improved. But sometimes that is harder to sell – particularly when you’re doing date based releases and you approach the deadline.
You do however need to tend and care for your system and for your users to make sure that you are slowly making progress about the stuff they care about – even if it isn’t the thing that will make the next big impact on the bottom line of the company selling the software.
Has it happened to you? It would be interesting to hear other people’s experiences with this. How have you solved it? As I suspect this is quite a common scenario.