When I first started working on an agile team, one of the habits I needed to develop was grooming the product backlog. In an agile environment my week-to-week and day-to-day focus quickly became more integrated with what the development team was working on each sprint. If I went into a sprint planning session without a properly-groomed backlog, the planning session was not as productive as it could have been. I learned quickly to stay at least one step (but only a step or two) ahead of the development team to maximize our productivity.
Realize that 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.
I’m sure 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 on, 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 often.
There is definitely a different requirements cadence when grooming the backlog versus finalizing a set of use cases or functional specifications. So I’d like to share some of the practices I’ve developed that seemed to benefit me and my teams.
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. 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 product 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”.
Of course, these aren’t the only tasks. Among other responsibilities, I’m also meeting with the business to flesh out ideas and opportunities for future releases. But to keep up with the sustained momentum of an agile development environment, grooming the product backlog for the immediate future often takes priority and is the most critical contribution I make to helping the development team be successful.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 2 trackbacks }
{ 2 comments… read them below or add one }
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.
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.