Member-only story
Write actionable backlog items
It’s easy, when backlogging your own product’s issues, to simply document the existence of the issue: “The app sometimes throws the error Cannot access property .includes of undefined.” It’s easy, when customers have the ability to open backlog items against your product, for them to do the same.
An actionable backlog item has a handful of important qualities. The problem with the above example is you and your team has nowhere to start. The issue isn’t reproducible; the root cause is unknown and undiscoverable. What happens when your team opens this item and simply cannot reproduce it? They wasted their time, and the item goes nowhere. Further, there is no definition of done: It’s perfectly likely a possible edge case was addressed somewhere in the app, but what if that was not the customer-impact error? The error still exists in production, impacting customers, but no longer sits in the backlog because the engineering team believes it to have been addressed.
I was recently asked to share the issue template I use when creating tasks, but I want to break it down a bit so that it can be better harnessed to your team’s needs.
