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

A retrospective on a planning talk

I gave a talk at SUSGA on Thursday evening.  The talk was entitled Release Planning with Scrum: Controlling the Chaos.  My slides can be seen here.

I think the talk went well.  I think it was well received overall.  We did touch on a couple of topics that weren’t specifically under the auspices of the talk that I’m sure I’ll blog about soon.  But the content itself seemed to be understood and generated much conversation – which is largely the point.

I did learn a couple of good things

  • When I know my content, I’m okay at presenting.  This is good 🙂
  • Karen had a great comment of how to deal with sizing of epics when turning them into smaller stories. Simply generate only as many stories as fit the number of points. Once you’re over that amount – either cut stories, or admit scope creep.  (And I would add – measure to understand the growth)
  • I don’t necessarily tow the party line in my view of certain topics.  I’m sure I’ll blog about some of those soon to explore both my thinking and hopefully get feedback from others.  That interaction/conversation in my mind is largely the point of why I blog so I’m sure it will be fun.

I would do a couple of things differently

  • I should have written up bullet points on the points that each group brought up so that they could be remembered and blogged.  I intended to, but I only remembered half way through the discussion.
  • I would touch a bit more on release planning versus releasing software – i.e. when you’ll get something versus when something will be live.  You still want to plan to know in a ball park manner how long it will take to get something specific even if you release software into the wild every sprint.
  • I practised a lot – which is great.  But based on that practice I should have changed my slides as by the time I got to the presentation I knew all the points around the points on the slides so I could possibly have achieved less PowerPoint hell.  Perhaps next time I’ll create two sets of slides – one to practice until I know what I want to say.  And the other the cool image laden slides that I can talk about.  Something to think on.  I’m not presenter type so I’ve got lots to improve around this.
  • I suspect one or two people do release planning very differently.  I should have stressed that this is the way that I have done it, and that I’ve found success, but by no means is this a blueprint for the only successful way to do release planning.  Between the PMI comment (that this is “practical agile”) and the comment that the talk was good as I presented my content well – there were certain people who possibly think what I’ve been doing is overkill and maybe not agile…  but I’d love to hear what the other options are in helping stakeholders understand and take part in what is happening.

The interesting thing is I wasn’t nervous until the hour or so before the talk.  That is progress too. I’m starting to get better at this public speaking thing.

Thanks to everyone for the support and positive vibe of the evening.  I think it was great.  And hopefully it inspired some ideas, thoughts and conversations in the community that we are.  If that is all that happens, then I’m happy.

And thanks to the Yellowtail crowd who made it out.  It was really great to see you all again 🙂

Tracking Progress

A while back I was part of a panel talking about tools at SPIN.  Peter Hundermark asked if I viewed the board or Jira as the final say over what was to be done.  I guiltily admitted that actually I have a spreadsheet that I consider the definitive.  This post is about that spreadsheet.

An example of what I’ve created over the last two years is my Product Overview spreadsheet.  In recompiling this today I’ve already identified several changes that I should make and several changes that would be nice to make.  But I’ll hold off on any of those until I’ve determined the needs of my current projects.  We shall see.

Ideally I’d like Jira to be able to do it for me.  The latest version seems to be doing more so I’ll see if I can automate this more – or replace it.  But previously I’ve been unable to get what I wanted from there.  And it can change from so many different angles that it may be hard to track.

Why yet another spreadsheet?

In order to identify trends in a release – you need to know how big it is and how fast you’re getting there so that you can plan against it.  If you’re not releasing every sprint – but rather every 3 months – or when it is ready – this can help you understand realistically what will be in the release – or when it will be ready.  This is a Good Thing.

I’ve found using this spreadsheet that planning medium term releases (4-6 sprints) can be very accurate.  Over the short term velocity may vary too much and over the long term too much will change.  But I’ve found that planning over the medium term can be very effective.

Some details:

The key page is the overview – as that is intended to inform as to how we’re really doing.  It covers the estimates of dates based on best, average, worst velocity.  In this version I’ve got a fixed date line for “Required” which helps manage to the date.

The product burnup is useful to understand the rate of change vs. the rate of progress.  If you draw a best fit line for the completed items and another along the change items – when those two lines are extrapolated to meet should be when you ship.

All the data is automatically generated from the other sheets.

The sheets are:
– Overview – executive summary
– Themes – if more detail is desired on the themes in progress
– Sprints – details on each sprint (sprint totals are generated from the completed backlog items)
– Changes – to enable the tracking for the product burnup
– Backlog – the backlog – estimates and sprints and status (complete or otherwise)

Pros:

I have found this spreadsheet invaluable in planning releases and discussing progress with stakeholders.  I keep it up to date and provide it after each sprint end and it keeps a simple eye on the progress of the release.

Cons:

It takes some effort to keep up to date.  If you keep on top of it, it is easy.  And it generally takes a 1/2 day or less to update.  But if it gets out of sync it can be a pain.

It would be lovely if Jira just did this for me 🙂  (Or I could export the data and add the forumalas on top of it more easily…)

Todos:

I’ve realised this weekend that the SUMIFS and COUNTIFS are not supported in OpenOffice – so I’ll need to do something about that (maybe).

I’d like to push the theme related stuff to the themes sheet and make the overview page even sparser.

It needs to be easier to change sprint length – or deal with changing dates due to public holidays changing the cadence – or to deal with hardening sprints when no points are planned (hence this _maybe_ shouldn’t influence the average velocity).  That is a bit of a pain at the moment.

After looking at this again this weekend, I can see some potential for refactoring – some DRY and SRP could be applied to some of the sheets I suspect.

In closing:

I’ve had great success using this spreadsheet.  Having the numbers and keeping on top of the empirical information lets you plan further ahead and help people understand what they will realistically see in a release based on real progress and due to real changes.  This is a Good Thing.