If you fail to plan, you plan to fail‘ – Benjamin Franklin

Effective Sprint PlanningIs it possible to shoot a goal if the goal post is constantly moving? I think not. So, how does one achieve a moving target? By dreaming.

The same principle applies in agile development. If the sprint is not sand boxed, it just becomes a moving target, thus making it imperative to do so. A moving target not only results in loss of valuable momentum but it demoralizes the team as it makes them a failure. Whereas, well-defined sprints at least lead to more predictable outcomes, sustained momentum and sense of achievement, which becomes a self-fulfilling prophecy to achieve success.

Over the period of years, I’ve come to realize the following points to be valuable prerequisites for an effective Sprint Planning meeting -

1. Have a Sprint Goal before the meeting

This is the guiding principle and defines the mandate for the Sprint. It becomes the benchmark to help the team select the right user stories to be implemented. When in doubt, this acts as a filter or lens through which the team decides what stays as part of the release and what must be discarded.

Good example of Sprint goals are -
a. “Enable SMS based delivery to our members for marketing related messages”
b. “Enabling Parents to see a magazine of their kids activities in school”
c. “Enabling our users to search for their uploaded documents”
d. “Enabling credit card payment wall at the time of sign up”

I’m sure you get the point. The more focused the Sprint goal, the better it is for the team to come together to achieve it. Unless the entire software development team is divided into multiple functional areas and one needs to have a Scrum of Scrums. Even in that case, every scrum team needs to have a single purpose or a goal, which they need to achieve. All of them just roll up at the uber Scrum Master level who gets to see different functional objectives at play.

2. Have a groomed product backlog related to priority
I’m not sure how could one have an effective Sprint planning if the product owner hasn’t groomed the product backlog by the business value. It’s an absolute must before the Sprint planning is initiated. The idea is to have all the user stories lined up correctly by the business value so that the team doesn’t have to second guess which user stories to pick if something is too big to be completed in a given Sprint.

If this hasn’t been done properly then sprint planning meeting would quickly degenerate into a lengthy-pointless-and-forcing-you-to-bang-your-head-against-the-wall kind of a Bollywood movie where the script doesn’t stick to the plot and every other scene is a display of creative genius of the director to showcase that how well he/she can digress.

3. Ensure all the stakeholders in the success of the Sprint are present and have read the user stories
I see way too many sprint planning meetings where the engineering team would come to the meeting without having any idea of the user stories to be discussed. Unfortunately, I end up canceling those meetings, as they quickly become an exercise for product owner to test their oratory skills. The poor guy not only has to write the user stories but end up explaining every single bit of it. Not worth it.

The ideal situation is for all the team members to have read the user stories, understand it to the best of their abilities, having a mental model of how it would fit in the existing system and having their questions ready. This smoothens the entire process and help the team being focused on selecting the user stories, estimating them and finalizing the Sprint Plan.

I’m sure there are other patterns of sprint planning success but performing the above drill before the sprint planning meetings have served us well.