Top 5 Montevideo Area Beaches

Sure, you do Sprint planning. But if you’re not doing Sprint pre-planning, even though it’s not an official defined Scrum process, you’re asking for trouble and delays.

That was the lesson I learned from a Scrum expert, based on our experience with the two seamless back-to-back meetings known as Sprint planning. In the first meeting, the product owners review the highest-priority items in the product backlog with the Scrum team, and decide how much work they can do within the Sprint based on their velocity in the previous Sprints. A game of planning poker is played and the user stories (or requirements) are rated based on the complexity, external dependency if any and amount of work involved. In the second meeting, the Scrum team decides how it is going to get the work done by breaking down the user stories into tasks and then commits to the Sprint plan.

Problems for the product owner often start from the word ‘Go’ since initially there are no priorities defined for items in the product backlog and all the team members may not have the same understanding of the user stories. The proceedings can then get delayed if a team member has a question about which the product owner must consult business users or stakeholders who aren’t present. Another challenge is to prioritize user stories carried over from previous sprints, which the product owner usually wants to complete because the team has already spent a considerable time on them.

This is why going into the Sprint planning meeting without some pre-planning discussions and follow ups will increase uncertainty about user stories and make life difficult for the team.

Pre-Planning Done Right

To make a Sprint planning meeting as effective as possible, the team will need:

• A fully prioritized product backlog.

• A list of user stories which the team can complete within a sprint, and

• Clear and well defined acceptance criteria for each user story.

Before holding this official planning meeting, I suggest a pre-planning meeting focusing on:

• Clarifying what constitutes a high-priority user story, and what is required to complete each specific user story.

• Raising any questions the product owner must answer, to give him or her time to contact stakeholders (especially if they’re in a different time zone).

• Providing a relative estimate of the size of user stories to help the product owner prioritize work on them.

• Breaking complicated user stories into smaller units that will fit within a Sprint.

• Understanding dependencies among user stories owned by different teams to decide which Sprint should work on them.

During this pre-planning process, whenever the participants cannot clearly identify the scope of work for a user story or the value it will bring stakeholders or business users, it is a sign that the team needs to clarify the scope. Work you do here will make your future progress faster.

Best Practice

One product owner I knew used the preplanning meeting to not only discuss the high priority user stories, but also to make sure different members had a common understanding of them despite language and cultural differences. He did most of the talking at the beginning, and then asked for questions. He also asked every team member to speak, which raised the confidence of some of those who tended to speak less.

These discussions revealed a lot of new information that helped refine estimates of the time and effort required to complete the user stories. They also clarified the acceptance criteria, helped the team visualize the different dependencies and set the expectations of the product owner about the complexity of the user story. That’s especially important for the timely completion of today’s projects that often involve multiple platforms with lots of dependencies.

Without a pre-planning meeting, teams can get lost in hours of lengthy discussion and still end up with some open, road block questions. Let me know if you agree these pre-planning sessions are critical, and your best practices for running them.

Harshal Sanjay Deole is a software developer with seven years experience in outsourced software development using both waterfall and agile scrum methodology.