How Backlog Grooming Sessions Helped Me Fail Faster Successfully

Artifacts (similar to ceremonies) seems like a very traditional (even archaic) word for relatively modern processes like Agile, but they are very important fundamentals to ensuring the process flows smoothly. In Scrum, there are three main artifacts: the product backlog, the sprint backlog and product increments.

More: Basics of Scrum, Sprints and Ceremonies

What are artifacts?

• Product Backlog – our team keeps a list of all of the features that we’d like to work on in the future in tickets in an application called Jira (a common tool for application development teams). Working with the business and senior management, I order all of the future features in a priority of what I want the team to work on next. From my experience, teams have different levels of details in each one of their backlog items. While including even the smallest request from the business (can you change the color of this grey to a slightly different grey?), the product owner has the responsibility to decide how important that change is compared to the other items in the list.
• Sprint Backlog – On the first day of a sprint (lasting 1-4 weeks), a team will pull items from the product backlog that they think they can complete within that timeframe. One of the important tenets of agile development is that the team has a lot of power in these discussions. While I’ve seen various teams implement their sprint backlog process in different ways, I’ve been most successful by following what I was taught in Scrum training. The team reviews the items at the top of the backlog and “accepts” them into the sprint.
• Product Increment – This is what gets released to the end users. The easiest way to think of this is as a version.

My Initial Issues with the backlog

I spend a vast majority of my time in the product and sprint backlogs with my team. I like to think of my job as “feed the beast”, which means I need to ensure that I have a well groomed backlog full of well thought out and clear stories in an organized manner so that when my development team needs a new story, there’s one ready to go immediately. When I joined the team, our backlog wasn’t quite in that condition, and I found myself scrambling during planning and throughout the sprint.

Over my first few sprints, I would organize the stories based on my (at the time limited) understanding of how the application worked and the new features being requested. Unfortunately, most of our stories hadn’t been thoroughly reviewed before sprint planning, and most of them hadn’t been estimated. When sprint planning came along, my team would point out flaws in the stories or let me know that certain features depended on other things being done first. My entire plan for the sprint would fail before we even got started leading to personal guilt and team frustration.

How did fast estimation help me?

While our team had backlog grooming sessions sessions, we weren’t getting through enough stories fast enough each week, and so sprint after sprint, we kept having the same types of issues. While searching for a potential solution, I came across the Fast Estimation process, and over the following weeks started to implement a version of it that worked with my team. As the team got more familiar with the new process, we were began going through more tickets faster. Because of that, we found two fantastic results:

1. Seeing more tickets sooner allowed the team to become familiar sooner with tickets to provide input in the planning process. They could see holistically how features were intertwined and give constructive ideas on how to more efficiently organize the stories.
2. The team provided invaluable feedback around clarifications needed on tickets much earlier in the process. When tickets didn’t meet their standards, I could take them back to work on improving and bring back for additional review later.

Simply by changing our process slightly in a way that allowed us to see more tickets faster, we began to quickly see improvements in other areas. Our sprint planning became a much smoother process because the team was familiar with the tickets ahead of time, and I spent less time answering questions mid-sprint because the quality of the stories in the tickets improved. It was a win all around.

Failing faster is a good thing

While most people think of failing as a bad thing, in software development, failing fast is a great thing. We want to know as soon as possible what isn’t going to work so we don’t spend more time than necessary on them. I view these backlog grooming sessions as opportunities to bring inadequate tickets forward earlier so that by the time the team is ready to work on them, we had fewer issues during the sprint. Within a few months, the number of tickets worked per sprint as well as the overall sprint velocity was began trending upwards as the ticket quality improved. Failing fast proved to be very successful.