As we all know, Product Managers are responsible for maintaining the Backlog such that it reflects the demands of the market. As market dynamics change, the backlog changes too. The Agile way of constantly prioritizing the backlog and keeping the most relevant features or stories at the top are key to ensuring that the product stays competitive in today’s dynamic market.

Many times, the Product Manager and the Product Development team go into Sprint Planning without enough clarity on some features or user stories. This causes the planning meeting to go in circles around these user stories without the user stories finally getting picked up for development, simply because there is not enough detail or the Product Manager needs to cycle back with the Business on some clarifications. This causes a delay in the feature being picked up and ripples down to a late deployment.

Despite his/her best efforts to make the stories “development-ready”, how can the Product Manager be sure that (s)he indeed has gathered all the needed information before stepping into the Sprint Planning meeting? This is where the Backlog Elaboration meeting comes in handy. Midway through the Sprint, the Product Manager assembles the team together and presents the priorities for the next Sprint to the team. The team and Product Manager go through each user story briefly and decide if the story is clear, has the necessary information, broken down to a proper size, the wireframes are ready, etc. Once all the information is available, the team can also assign point estimates to the story. The Product Manager and the team perform this exercise for all the user stories tentatively planned for the next Sprint.

Advantages of this exercise.

• The Product Manager knows if there are any shortcomings in the user stories before the Sprint Planning meeting and has time before the Sprint Planning meeting to collate the required information.
• The Product Manager has a fair idea before the Sprint Planning meeting about the size of the stories and knows how much might get done (based on the team’s Sprint velocity).
• The team knows the nature of the user stories coming up and can gear up for them and raise any environment setup or training needs up front.
• The Scrum Master gets an idea of the kind of challenges the team might face and can prepare to mitigate them up front.
• The Sprint Planning meetings end up being much shorter and more productive since  most of the stories have been discussed earlier.

Disadvantage:

• The Elaboration exercise might temporarily distract the team and take them away from focusing on the goal of the current Sprint.

One of the teams that I worked with followed 2 week Sprints, where the Sprint planning would happen on the first day of the Sprint and the Elaboration meeting would happen exactly one week later. Initially, the Product Manager got many inputs from the team on the user stories in the Elaboration meetings. These were taken care of before the Sprint planning meetings. Over time, both the Elaboration and Sprint Planning meetings shrunk in duration and the entire team reaped the benefits of better planning and proper elaboration.

Do let me know if this is something that could work for you.