Getting low priority work Done

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.

Prioritised backlog

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.

But

  • 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.

Some scenarios

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.

Advertisements

2 comments on “Getting low priority work Done

  1. From my experience the x % of low priority items in a sprint just does not work. Who chooses these stories? What really falls into this bucket? Is it really worth the admin to essentially keep two backlogs? I have seen with a couple of project managers that the debates around the low priority items took more time than actually writing the code to complete them, but still left most developers unsatisfied (possibly end users as well) and gave the PO higher productivity expectations.

    The low priority bucket then gets polluted with more hidden high priority work. Should there then be a x % of low priority items done in a sprint from the low priority list? Does the priority of the list count in reverse? The low priority items in my opinion is part of the pain of being a project owner. One backlog without having a team to wonder about which bucket to select from is much more efficient.

    Polishing parts of the application probably does not have a high return on investment, but it certainly makes the application more professional and certainly gives the developers more pride in their work, so it is I believe it is important.

    I would like to think that most developers have a good sense of what needs to be fixed, since I cannot count how many times I have heard the phrase “I know it is bad, but it is not a priority right now”.

    In my fantasy world, as a developer, I would like a single backlog where developers can literally vote some stories up or down based on personal preference and good client feedback with a project owner that knows how to evaluate the developers’ opinion. This will bring the “if it was my project” aspect into the game getting more out of developers than bargained for.

    • patrickvine says:

      Thanks Wilhelm!

      Yes 🙂 I suspect this all comes back to actually building software around a sustainable pace focuses around motivated individuals. When the team dynamic is working really well the PO will be working with the team and giving them the slack to Do The Right Thing as much as possible. Like when velocity becomes the target – things go back. Similarly prioritising only the Next Big Epic can result in non-ideal dynamics.

      I like the dev votes idea! One has to attempt to keep the holistic view of the entire system, the team building it, the customers, etc in mind – not just the next feature.

      Take care,
      -Patrick

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s