Build Your Backlog
In my previous post, we talked about gathering requirements. This post will discuss getting those requirements into an epic-level backlog.
There are three things I think about when building a backlog.
- Hidden assumptions
- Estimates
- Act of building a backlog
When we start this process, we must keep in mind the danger of incomplete pictures. The danger is real and often happens on many projects.
There is a famous picture of a tree swing and how everyone envisioned what the customer wanted.
Everyone had it wrong.
This will happen on all projects, but with some effort, we can reduce the likelihood of going too far off course. The problem of misaligned requirements is not new; it exists in all fields that focus on building things. Software is particularly tricky because we are not building physical things; we are building virtual things (just 0s and 1s).
To ensure a common picture, it is important to have many ways to present a project.
- Many people think of UI in terms of design. Having a strong UI design before building a project is crucial for ensuring a shared understanding.
- Acceptance criteria provide an opportunity to capture more detail than a few mockups or wireframes can provide.
But one of the best ways to ensure we get what we want is estimation.
Yes, estimation.
While estimation may not be the only option, it’s likely the most effective one. Reviewing the backlog with others can lead to surprising insights, but the most valuable step is actively going through the estimation process. It can be challenging and uncomfortable, but the results are worth it.
Other good practices include conducting team-wide backlog reviews and approaching the backlog from multiple angles. For example, you could create one version from the user’s perspective, and another focused on the necessary components to be built.
Estimation forces people to engage with the requirements. It is easy to look at a backlog and give it a passing understanding. But when you are asked how long something will take to build, we all suddenly ask better questions.
The sooner you start building a backlog, the better. Ideally, you will start almost immediately. Waiting until one week out from building the product isn’t ideal, and building your backlog while building the software isn’t ideal. But what is ideal?
You want a backlog for a good amount of work—ideally, at least a few months for a team. No one person should build this backlog in isolation. The building of a backlog should include product owners, project managers, developers, leads, software architects, and testers. We want everyone involved if we can. And when it comes to estimating a backlog, the more involved, the better.
The backlog should clearly communicate what we intend to build without looking at other artifacts.
