"A DevOps is You!"
Log in
Don't Write Issues, Write Ideas
planning / project management
May 25th, 2022 by will

The Backlog

The place where all future issues are put. Anything a team member needs to take note of gets thrown here. We say it’s our pantry of work to pull from but in reality it ends up being more of an attic. The things we want to see are at the top, easily accessible, while everything we want to ignore gets pushed lower and lower. Under the issues that are actual sprint candidates are various production impacting bugs and the remaining work needed to bring that last POC into a full feature. Going deeper are the user stories for initiatives that upper management has long forgotten about. Down in the graveyard depths of the backlog, all the random bugs and tech debt the team has found along the way. Once in a while someone will come through and see them and think “that would be a good thing to do, maybe one day,” but that day is always tomorrow.

Where Did All These Chickens Come From?

Issues are easier to write than they are to read. Ideas are easier to come by than implementations. Reducing friction in creating issues is not in itself a bad thing, if done purposefully. The problem we run into is carelessly throwing everything that pops into our heads into the pile. I am as guilty of it, if not moreso. We can reduce the noise and still document everything that needs to be done.

Stop Writing Issues

Write ideas, not issues. We want to believe that issues could fit into the Eisenhow Matrix but the reality is issues are either urgent and important, or they end up meaningless and closed. The big problem with stale issues is the information goes out of date, if it was relevant in the first place. I may make an issue to upgrade Memcached, but by the time we get around to upgrading it we have switched to Redis. If it took a while to get to the issue, was it really meaningful? Stop writing down the actions needed to be taken. Instead of “Upgrade Memcached” write a story for “Upgrade audit for caching service”, or better yet “Process for ensuring caching service is kept updated.” Stories are not tasks. Tasks are not stories. A story should describe a tangible business need without technical details. Once the story is assigned, then the technical details, relevant to that point in time, can be filled in.

Writing Issues Thoughtfully

Another issue with issues is lack of information, especially context. The issue for “Upgrade Memcached” says nothing about why it needs upgrading, if there are any caveats (maybe we need to pin versions), or where the ask came from. There are a lot of different ways of writing stories, but each one should include a basic set of questions:

  1. Why do we need the change
  2. What do we currently have
  3. Where do we want to go
  4. When does this need to get done

Point #1 is the business requirement. It is what the ask coming down the pipe should be. If it is not, then it is likely an XY problem and additional clarification should be raised to stakeholders. #2 and #3 deal with comparing the shape we are in versus what the final shape should look like, these can even be the same bullet point. #4 is the deadline.

Example description: “We must upgrade our caching system by Q4, we are on Memcached version 1.4 and all of our tertiary services must be at a latest point release for our yearly audit”

This says it all, why do we need it, what we have now, what we need to go to, and when it needs to be done. It does not delve into the details or make assumptions what the service will be by Q4, just that it needs to be at the latest point release.

Tracking the Technical Details

Most issue systems allow checkboxes or subtasks. Whereas stories are independent and cohesive sets of work on overarching epics, tasks or subtasks can be individual cohesive sets of work on stories. Having multiple tasks per story also gives the benefit of breaking the work down, which has the side effect of being easier to report up. Not all stories need subtasks either, simply adding a “How” to the description could be enough once the issue is assigned.

All of this applies to operational tasks and bug reports, not just feature requests. At the end of the day, anyone should be able to pull up a backlogged item and read off the title and description and anyone will have a clear idea of what needs to be done. Keeping backlogs to ideas, rather than implementaiton details, will help reduce both the amount and irrelevance of the backlog.