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.
There is definitely a different requirements cadence when grooming the backlog versus finalizing a set of use cases or functional specifications.
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.
Pingback: How to Define Scope in an Epic | VaughnPaul.com
Pingback: Can the Agile Approach Work for a Non-System Process Change?
Pingback: An Agile Functional Specification | Business, Technology and the Future
I usually start with defining what different modules are to be developed. This is because, in realistic conditions, a final list of features is never there. There are always “some last minute changes”. So I begin with the entry and exit points and group the modules which have similar functionality. e.g. when u select or click something a list comes up. So now no matter what a user will select there will be a list. So i define the stories based on this and later add more stories specific to the item in question.
Hi lovneet,
Yes, I think adding new stories will also work. What I find when I do that, however, is that the discrete stories start to lose their value, so the value statements we put on them at the beginning that led to the initial priority might not be quite as correct once that story gets split up. This can also lead to a bunch of unfinished features because we did the primary stories but not the extra ones added. Do you run into this situation too? And, if so, how do you deal with it?
Pingback: Best Links of the Week – Christmas 2009 Version : Agile PM Scrum
Thanks, Robert. Yes, we are definitely clarifying requirements as we go. Oftentimes new requirements surface in terms of system integration or changes to business rules that are “hidden” within the application (i.e. I could not discern them from talking to the business or exploring the system). We try to use our judgment as we uncover these. If they are small, we finish them within the sprint. If they are significant and would delay the sprint, we create new stories and add them to the next sprint.
Quite honestly, this has always been a challenging point with me in agile requirements. On the one hand, the stories are supposed to be a reminder to have a conversation, which means to me that there are ambiguous requirements. On the other, most of the teams I’ve worked on consider very minor details a “change” that impacts their commitment within a sprint. We are also a distributed team which adds another layer of complexity and means there simply has to be a lot of detail in the stories or we risk communication issues.
I try to aim for balance: enough detail to create alignment, but not so much that there is no reason to talk about it. And then we supplement with additional detail as we talk.
Great post Laura. It sounds like you have it down.
One question I have is on this part of your post, “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’.”
Does this mean that you are “clarifying” requirements as you go? If so, how does this effect the total amount of work required to complete a story, and then how does that affect the overall sprint?
Thanks for your time and response.
Pingback: Tweets that mention Grooming the product backlog: agile requirements management for improved sprint planning -- Topsy.com