A common misconception about Agile Product Development is around “just-in-time” planning. It’s important to not have all of your requirements for the next six months fully defined (because even the smallest changes will definitely require rework), but it’s equally as important for a Product Owner to be working 1-2 sprints ahead of her development team. This way, everybody has an understanding of what’s on the horizon.

Recently I joined a team as an interim Product Owner, where on my first day I literally walked into my new assignment and into the Sprint 1 Planning meeting. Very quickly I learned that my role would become very challenging – there was no product backlog! Additionally, it also became apparent that the Sprint 1 stories did not meet the definition of ready. As soon as we started sprinting, I had team members finding requirements gaps, which required more user story refinement and creation of additional acceptance criteria within the current sprint. Since I was devoting time to refining stories in the current sprint, it was equally as challenging to start forming a backlog. And boy, did not having a backlog come with a whole other set of problems:

1. The UX team did not have a long enough runway. Since we did not have a backlog, I would need mock-ups for user stories that would be needed in a couple of days for grooming meetings. This was unfair to the UX team, as their input generally requires a lot more time and thought poured into creating solutions.
2. External stakeholders did not get enough advance notice of change management requirements. The company was great at having all of the right communication channels open to notify the right teams of changes (customer service, training manuals, etc.), but without knowing what was coming in two sprints, they had to scramble to update training and communications materials once we were able to figure out what was going into the next sprint. Often, they would ask for mock-ups to include in their deliverables…which were usually delivered late when you look at Problem 1.
3. The Development team did not have enough time to groom stories. Often they had to groom brand-new stories two days before Sprint Planning started, because I’d often scramble to write the stories moments before our grooming sessions. As a result, Sprint Planning slowed as the team attempted to refine these stories to help them meet the definition of ready.

Did we crash and burn? Nope, we as a team held it together! Within two sprints (two very painful sprints), we were able to dig ourselves out of the backlog hole. I spent a few extra evenings getting more stories written, spent more time with stakeholders to elicit and refine requirements, and the rest of the team made themselves available for additional grooming time. Fortunately, everybody had a great understanding of the team’s shared goals, and we all pitched in to help each other keep our sprints running.

Have you ever had to balance a backlog deficit? I’d love to hear your stories!