How to have your Nice To Haves

David Glover
Jul 27, 2017 · 6 min read

We’ve all got Nice to Have items in our backlogs, right? You might not call them that, but I’m sure you know the things I mean.

You know you want it…

They are those tickets that would be so great to see ticked off and moved into the Done column. Those bits of work which really scratch a certain itch for you or your team, but don’t have an real, obvious benefit your customers, certainly not compared to everything else you have above it in the list.

A database refactor, for example. Not an important one, but one that fixes an annoying normalisation issue. It would provide no measurable benefit in performance or stability or anything else, it’d just be nicer to work with. Or maybe it’s some additional logging to allow you to build a report that nobody but you would really care about. Or perhaps it’s making your documentation micro-site a bit prettier and nicer to read.

Maybe just one slice?

These are all good things to do, no question about it, but when you also have work items on the list that actual solve production issues, or improve customer retention, or will help to close a major new deal, then how can you ever justify doing the Nice To Haves instead of those Must Haves or Should Haves?

The answer, by the way, is that you obviously can’t. If you care about building a good product then you’re not selfish about it. You fundamentally can’t be. Your needs are not as important as the customers, end of discussion. It’s Product Management 101: Do the most important, most valuable thing first.

That’s why these tickets languish at the bottom at all of our backlogs, for years on end in some cases. These are all bits of work that we’d love to do and you feel bad for not doing them, and feel even worse telling other people they can’t have them.

You feel bad every time you scan down the backlog to see what can be pruned, read it again and think “yeah, we really should do that” but yet again you can’t justify promoting it up the list.

You feel bad every time you say to a developer “yeah sounds good, create a ticket and we’ll prioritise it” and you see the look in their eyes as they know you’ve just thrown their idea into blackhole of Nice to Have.

You feel bad that you’re making the right decision and it sucks.

Calories don’t count on Thursdays, right?

It sucks because, damn it, you are a customer of your product. The whole team is, even if they never actually use it. The experience of building and working on a product impacts you and your team; life is too damn short to ignore your own morale.

This is the small stuff that you should be allowed to sweat. The stuff that just makes something that little bit better, even if only you notice. It’s the pet projects, the things we care about even they aren’t important. I know the right decision is to have a salad for lunch but goddamnit I want a burrito.

So we figured out a way we could have our cake (or burrito) and eat it too.

I’ll be honest, writing this article is really making me hungry

The answer, funnily enough, is story points & velocity.

Now, I’ll happily tell anyone who can listen that the least useful thing I get out of an estimation session is the actual estimate. (It’s the sitting around and discussing the ticket in detail as a team that’s important.) Hell, I’ll cancel our fortnightly estimation sessions more often than run them. But in this case I’d make an exception to that statement.

Also, to be clear, I’m not advocating sitting there and estimating all of your Nice to Haves. That’s madness.

But you know your team’s average story point velocity, and you know how many people are on holiday or training or whatever in the next sprint, so you can estimate how many points you should be able to complete in that sprint. Right? If you’re doing Scrum then this is what you’re already doing.

And you take that velocity number and you fill your sprint up with your current top priorities (or however you choose to do it) until you hit that number. Or thereabouts.

And you tell your stakeholders that list of tickets is what you are going to commit to attempting to deliver this sprint.

Hopefully I’ve not said anything unusual there. But it’s the next thing that we started to do differently.

Simply add to the bottom of the sprint’s To Do column two or three tickets from the top of your Nice to Have list. (And while I don’t suggest estimating your Nice to Haves, I do suggest prioritising them.)

There will be a very good chance you won’t get to them. After all, most sprints don’t come off perfectly. But by the law of averages some of them will go better than others.

And on those sprints you get to pick up a Nice to Have.

There is no downside to this. Your stakeholders and customers are happy because you’re delivering what you’ve said you’ll deliver when you said you’d do it. You’re not lying to anyone at any point. You’re not trying to sneak work in behind people’s back or anything damaging to your product. You just get a free win.

This doesn’t work if you constantly over-stuff your sprints. But then if you are doing that STOP IT AT ONCE. You are literally helping no-one with that nonsense. If you find that every sprint ends with tickets left over untouched (that weren’t Nice To Haves) then you’ve got your estimation or planning processes wrong. Go fix them first then come back to this.

The most ridiculous thing about this, is that it works! You’ll probably only get three or four Nice to Haves into that Done column every quarter, but that’s enough to feel like progress. The Nice to Have section of your backlog might still be a blackhole, but at least you’ve discovered Hawking radiation.

That metaphor may need work.

In our team we’ve been running with this method for around 9 months now and I’ve been very happy with it. It’s such a simple thing but at the time it felt like a revelation. And when it came up in conversation with other product teams, they all reacted with something along the lines of “huh, I should definitely try that!” so I figured I’d offer it to you, The Internet, in the hopes that it might help you too. (And if you do try it, let me know how you get on!)

I would love to hear other tips and tricks for dealing with the daily frustrations of life in software engineering/product management, so please message me or add them to the comments of this.

Oh, and if working in a place where teams have the autonomy to play around with things like this, then have a look at what jobs we’ve currently hiring for: http://careerssearch.bbc.co.uk/jobs/custom/?fields%5b32%5d=569

David Glover

Written by

Senior Product Manager at the BBC. An optimistic cynic, a lazy perfectionist and a newcomer to blogging. Be gentle.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade