In an agile environment your week-to-week and day-to-day focus quickly can become integrated with what the development team was working on each sprint. If you go into a sprint planning session without a properly-groomed backlog, the planning session may not be as productive as it could have been.
When working as an agile business analyst, I’ve learned to stay at least one step (but only a step or two) ahead of the development team to maximize our productivity. Let’s look at what the process of grooming the product backlog looks like and how it improves productivity.
Requirements Drive Planning in Agile
In agile, requirements (or user stories) drive planning. Requirements are managed in a product backlog of user stories. The user stories are ranked by priority and the highest priority items are detailed out.
There are differing opinions on what should be done prior to sprint planning vs. what should be done within sprint planning. On the teams I’ve participated in, we focus sprint planning sessions on understanding a handful of user stories in detail and planning the tasks it will take to complete the stories.
This means that prior to planning I have prioritized the backlog, detailed out the user stories with conditions of acceptance, and collaborated with the development team on an estimate for each story. In many cases I found that estimates actually helped the business prioritize, so we estimated early and we estimate often.
Meet Regularly with Software Developers about New Stories
I meet regularly with my software developers to talk about new stories and requirements that are being considered. In these discussions, we estimate the story if we have enough information. I also ask questions to understand the constraints. Oftentimes I’ll come away with information about how we can constrain a story to keep it small or what detailed requirements would require additional work. If there is not enough information to estimate the story, I come away with some open questions I can follow up on so we can estimate it the next time.
Sometimes these discussions reveal that something I thought was fairly small is actually a larger story and needs to be broken up, or what you might call an epic. All of this information helps me create a backlog that the developers can work with during planning.
Prioritize the Product Backlog
Most SCRUM and agile books will tell you to rank prioritize the entire product backlog. In my experience, this practice creates an extremely large amount of overhead. The value in rank prioritization is really with the product backlog items that might be addressed in the next few sprints. As such, I tend to break product backlog items up into releases or group them together in a general priority. Then, for the items that we have the capacity to address in the next few sprints I help the business rank prioritize.
Detail out the Highest Priority Backlog Items
As we head into sprint planning, I ensure that the highest priority product backlog items have detailed requirements behind them. These detailed requirements are captured in user stories. Along with the requirements for the story, I draft conditions of acceptance or the tests that need to pass in order for the story to be considered “done”. During sprint planning, we review the requirements in detail and often adjust them for clarity or to answer questions that come up. During the sprint, if the developer discovers a new condition or rule, we’ll often continue to adjust the user story so that the entire team has a shared concept of “done.”
To keep up with the sustained momentum of an agile development environment, grooming the product backlog for the immediate future is often the most important task a business analyst can do to help make the development team successful.
>> Learn More About Agile Requirements
Check out Use Cases and Wireframes – our virtual, instructor supported, professional credit course, where you’ll learn how to iteratively analyze and model functional requirements, and break apart use cases into user stories.