I have found over the years that the better a backlog is broken down the smoother the implementation of that backlog is.
I have found that the single greatest influencer in the success or failure of a backlog is the process of breaking it down.
What does it mean to break down a backlog?
Before we can really discuss how to break down a backlog it is worth taking a minute to discuss what I mean by breaking down a backlog. If you are following some kind of Agile process, you probably have a story board. On that story board you probably have a swim lane dedicated to a step that is just before the development of the backlog is ready to begin.
The process of breaking down a backlog is moving a backlog from the state of selected for implementation to that state of ready for implementation. Different teams indicate this transition in different ways, but most teams have some way of indicating that a backlog is ready to be worked on. So when I talk about breaking down a backlog, I mean the process of moving a backlog into a state where it is ready to be developed.
Why break down a backlog?
So why do we want to do this thing? Why don’t we simply pick up a backlog and start developing it?
The main reason we take the time to break down a backlog is because we adhere to the old philosophy of measuring twice and cutting once.
The process of breaking down a backlog is the process of thinking ahead to lay out a path which we can follow to the successful completion of a backlog.
By skipping this crucial step, we almost inevitably set ourselves up for failure.
Not breaking down a backlog to me is like going on a week long camping trip by taking with you everything you happen to have in your car rather than carefully planning out what you’ll need.
Packing the right gear
Now that we have talked about what breaking down a backlog is and why we should do it, let’s talk about the steps that are involved.
Step 1: Review the backlog as it is
In this step our goal is to understand the backlog and evaluate the kinds of questions that we will need to ask about the backlog and the areas of code that will likely be affected by the implementation of the backlog.
We will want to carefully read the backlog and try to understand the basic idea of what is being asked for.
We want to look for any kind of trouble areas that either indicate what is being asked for will not be possible, or that it will require significant architectural changes to the existing system or paradigm.
We also want to look for indications that a backlog might be too large and actually might be a fatlog that will need to be broken down into smaller backlogs.
Step 2: Pre-review the affected area of code
After we have gotten enough of a gist of what the backlog entails we should have an idea of the area of code involved. It is important to take a look at the area of code that is going to likely be affected by the implementation of the backlog so that we know what we are getting ourselves into.
Nothing it worse than thinking something is going to be easy to implement then actually looking at the code and finding out that it is a total mess that has to be cleaned up before anything can be done with it.
Our goal here is not to solve the problem or even to outline the solution. We just want to have enough education about the affected code to be able to have a conversation with the business about what will need to be done to implement this backlog.
Step 3: Initial discussion with the business and QA
Armed with an understanding of the basic idea of the backlog and the areas of code that are likely to be affected, we are ready to talk to the business and QA about the backlog.
The goal here is to fully understand what is going to be implemented and what the goal of the backlog is.
We have QA here so that both the development team and QA get the same understanding of the backlog at the same time. We don’t want QA or the development team dictating what they think the backlog means. If it is at all possible, it is important to get someone responsible for the backlog from the business to tell both parties exactly what they want.
Step 4: Define skeleton tests
Before we leave the initial discussion about the backlog, we want to come away with an initial skeleton of tests that everyone has agreed upon. This is a very important step that is often ignored, because often teams think that QA will just go off and write some tests.
It is important to make sure that everyone, including developers and the business, has agreed to the general tests that are going to be used to qualify the backlog as done.
Without knowing exactly what criteria will be used to judge the completion of a backlog and agreeing to it up front, you may be committing yourself to whatever the whims of either QA or the business are at any given time.
Defining skeletons tests help to define scope. It doesn’t mean that requirements and details can’t change, but it does mean that the current set of requirements and criteria is well enough understood for development to begin.
I often call the skeleton tests “done criteria.” At times I have actually reworded a backlog to explicitly state the done criteria that has been agreed upon after this meeting.
Something similar to
This backlog is done when:
- I can create a new user
- I can see that the new user exists from the admin tool
- The creation of the new user is audited and specifies details about the creation of the user.
Step 5: Task out the backlog
If you can’t task out a backlog, you don’t clearly understand what you need to do to accomplish the goal.
Tasking out the backlog is the process of breaking down and identifying the steps required to implement the backlog. I often try to make done criteria be in the form of business language and tasks be in the form of implementation details.
Tasking out a backlog can be a cumbersome process, but it is akin to mapping out a trip before and carefully packing your supplies before heading out on the road. When I am tasking out a backlog, I try to think of each sequential step that is required in order to completely implement the backlog. Part of this process often involves the actual design of the solution, because without some kind of design it is often difficult to create a series of steps to get to the end goal.
This is one of the reasons why I see tasking as so important, it ensures proper upfront design.
Many Agile teams think that Agile means no upfront design. This simply is not true.
Agile means that we don’t upfront design the whole system, but we should always try to design something to some degree before we implement it. Especially in a complex system. Tasking also helps to split the backlog up into workable pieces that can be worked on by different members of the team either jointly or in isolation. It is very difficult to coordinate work on a single backlog item when it isn’t properly tasked out.
I often like to define done criteria for each task in order to make sure that anyone picking up a given task will understand when it is complete.
One thing to watch out for is whether certain tasks are sequential or if they can be done in parallel. When possible, dividing up a backlog into parallel tasks is preferred, but many times tasks must be sequentially implemented.
Ready, set, GO!
Following these steps might seem a bit cumbersome to your development process, but I can assure you that if you take the time to implement this process you will not regret it.
Taking the time up front to clearly define the work that is going to be done on a backlog can save huge amounts of time that can be wasted reworking a solution that hasn’t been thought out clearly.
Here is a short recap of the steps for breaking down a backlog:
- Review the backlog
- Review the code affected by the backlog
- Discuss with the business and QA
- Define skeleton tests and / or done criteria
- Task out the backlog
Reference: How to Break Down a Backlog from our JCG partner John Sonmez at the Making the Complex Simple blog.
