THE PERFECT BACKLOG DOESN'T EXI...
It’s not entirely uncommon that software development projects get a bit chaotic and unorganized, with the development team just aimlessly rushing to refactor, fix bugs and add features, hoping to eventually turn things around. The overwhelming workload can create a sense that there’s no time to waste on planning or finding a better structure. As a result of that stakeholders might be getting frustrated because it’s not clear what’s being worked on and why and the few estimates they get often turn out to be wishful thinking. In this article we will discuss some of the potential ways to tackle these kinds of problems by improving the backlog quality and the process of working with it.
WHAT IS A USER STORY?
A user story can be thought of as a brief, high-level description of a bug or desired feature from the perspective of the end user. It typically emphasizes the user's role, the goal they want to achieve, and the benefit they expect to gain from the feature in a simple and understandable format. Since user stories don’t get into technical details or implementation specifics, they can likely be understood by anyone in the organization. A clear, well-crafted user story is a great starting point for any initiative within the project, but it does not guarantee that the process of breaking it into actionable tasks is successful.
CRAFTING CLEAR BACKLOG TICKETS
A backlog ticket can be thought of as a more detailed representation of such an initiative, where it is broken down into tasks, acceptance criteria and estimated effort. Depending on what your process looks like, it can be derived from the user story. While a user story focuses on the initiative from the user’s perspective, a backlog ticket puts more emphasis on how it is to be implemented.
When creating a backlog ticket, there are some things you’re going to have to sort out:
1. Who’s calling the shots? You will have to figure out who’s in charge of the current initiative. Having someone responsible for signing off on and prioritizing the backlog ticket, as well as following up on the progress and results is important.
2. Do you have everything you need? Sometimes a feature depends on another feature being finished to be implemented, or even refined. Other times it requires you to do some research to make sure that it’s even possible, given the current circumstances. Some features have external dependencies, like a design or a more detailed specification having to be produced.
3. What are the necessary steps? You will also have to understand what actions need to be carried out to achieve the desired result and define them as tasks. The better of an understanding you have of the prerequisites, the more accurate and clearly you can define these tasks. Try to be exhaustive and cover any tasks that could be considered “outside of” implementing the feature itself. This could include adding translations, writing tests, having the code reviewed, updating documentation and deploying to the target environment.
4. Which requirements need to be fulfilled? You’re going to want to define a set of specific conditions that need to be met for the backlog ticket to be considered complete, also known as acceptance criteria. Like user stories, acceptance criteria are often written from the perspective of the user, which can help facilitate communication with stakeholders and prevent misunderstanding. They should be measurable, testable and unambiguous, so that they can be easily verified by the end of the production phase. Clearly defining any boundaries can help ensure that the scope doesn’t grow beyond what was originally intended.
5. What will it take? One of the hardest parts of refining a backlog ticket is estimating the effort, or time, that’s going to go into it. Having an exhaustive list of clearly defined tasks does go a long way, but there are more things to consider. If there are a lot of unknowns, it can be a good idea to create a separate research ticket to clear that up, before finishing refining and estimating the ticket. If there are examples of similar tasks completed in the past, using them as a reference can give you a better idea of the scope.
Who works on the ticket, and their familiarity with the associated part of the code, also plays into the amount of time that’s going to be required. One approach, that takes advantage of the different perspectives within the group, is doing a blind vote followed by a discussion aiming to find a collective answer. This prevents the team members from getting influenced by each other’s answers initially. Using points as an abstract representation of the time or effort one feature will demand, relative to another, can also make the estimation process a lot easier.
A BACKLOG TICKET IS ONLY AS GOOD AS ITS LEAST GENEROUS READ
Consistency and thoroughness are key to a well-functioning refinement process. In a busy agile team you can't always predict exactly who will work on what, so you shouldn’t refine tickets with the assumption that a specific person will work on it. Ideally every team member is able to understand and explain the process and goal of each ticket without a whole lot of additional context.
A good exercise could be, when someone takes on a new ticket, for them to try and explain it in their own words. This will give you an indication of how straight-forward your tickets are before you start working on them. If you for example do a retrospective meeting at the end of each sprint, you could also revisit the ticket and see how well it describes the work it entailed and how well the result matches the desired outcome. Taking note of things that you consistently forget to account for or underestimate in your tickets can greatly help you improve your refinement process moving forward.
Maybe there’s no such thing as a perfect backlog ticket, you just have to do your best with the time you get to spend on refining them. But making sure each ticket provides as much of the necessary information as possible, and continuously evaluating and improving the process of creating them, is at least going to put you in a position to succeed.
