Software is never “done”. Instead, we continually improve it over time. We can mark how the software changes over time in terms of “Releases”. Simply put, a release is nothing more than a set of expected functionality - work completed within a named period of time. Note that releases are separate from deployments. We may deploy dozens, or even hundreds, of times before a release is over. A release simply marks the point in time when we have completed that set of expected functionality.
Work is often found in a backlog, but the backlog does nothing to help visualize what the system does. I propose creating a structure to the backlog, so that it describes the system. This idea is a story map. I strongly suggest reading Jeff Patton’s introduction of the Story Map.
The idea is that work is categorized along the User Journey:
The User Activity is described in abstract terms. Because of this, all types of work related to the activity: bugs, “maintenance”, and new features, can all be categorized underneath it. Activities “flow” sequentially from left to right, according to how the user goes through the software (the journey). Activities are then broken down into tasks. Tasks, like Activities, are abstract and should imply no implementation. If done well, organizing work becomes trivial. Most times, work is part of something that already exists. Sometimes, we do greenfield or novel work that adds to the user journey. Sometimes, our understanding of the system becomes clearer, putting parts of the journey on the map that was commingled with something else (we might “feel” this when we aren’t sure where to categorize work). Cross-cutting work, eg: localization, should be represented where it applies. It’s likely that there is localization work in many different tasks - so show it! This helps create clarity, define the level of effort, and break down the work into more manageable pieces.
Imagine a horizontal line running all the way across the story map. That line represents the release. Everything above the line is the expected set of functionality for the release. Everything below it comes later. This creates clarity in prioritization - if work is above the line, it’s in the current release! Coupled with the way stories are organized, it’s very easy to look at the map and see what areas of the software are getting the most attention for a release. It also makes handling unplanned work easier to visualize. A bug comes in, you place it under the appropriate Activity-Task, and either above or below the release line.
Ideally, a map is on a physical wall with index cards. But we are not colocated. The next best thing might be an “infinite workspace” tool, like Mural. Trello could likely be made to work.