When doing sprint planning meetings we always care about the big user stories. Stories that help the users solve real big problems. But what about the small things that hides in our backlog? These got almost forgotten, marked as “’should be fixed” but “not so important”. Sometimes it would be just a 3 hour job to make pasting pictures from the clipboard into the software work, but we won’t have the time. It’s not in our sprint goals. We have the same problems at Atlassian and that’s why we used a similar concept as Ubuntu is doing for their Linux OS: Paper Cut Bugs!
What are Paper Cut Bugs?
Paper cut bugs are the “low hanging fruits” that get left behind or forgotten. Things that annoys people in their daily work, that would make a huge different and that are often trivial to fix.
- A bug, UI annoyance, or an unintended problem occurring within an existing piece of software,
- the presence of which makes the product more difficult or less pleasant to use,
- that is easy to fix,
- that the average user would encounter…
- in a default installation of the latest release.
It’s only a Paper Cut Bug if all of the points are fulfilled.
Identifying Paper Cut bugs?
We went through our backlog and marked all issues that looked like paper cut bugs. For new issues the team should collectively decide if this could be a pear cut or a bigger / not so annoying problem. Depending on the size of the backlog and off course how good you have been in the past on fixing these small issues you could end up with lots of those. For JIRA Agile we identified around 50 of those nasty small things that we wanted to get rid of and that our customer hated.
Planning with Paper Cut Bugs
We took those bugs and planned 3-4 of those for a one week sprint. We allocate a few story points for Paper Cuts each sprint and started to fix those. It helped us to still deliver defined “Business Value” and also bring a smile on our customers faces when they found out that it’s now easier to use the software because of a fixed paper cut bug.
So what’s in it?
There’s a lot in it: Issues that customer requested a long time ago gets fixed, the support spends less time explaining small workarounds, happier customers and HAPPIER DEVELOPERS, because at the end of the sprint you have a feeling that you achieved something small but important.
Sven Peters 