Tarun3 Prerequisites for Effective Sprint Planning in an Agile Environment

November 5th, 2013 in Agile, Software Development by

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.

  • Pingback: Dew Drop – November 6, 2013 (#1661) | Morning Dew

  • Shalvika

    Thanks for sharing these. We have seen how setting the Sprint goal helps to crystallize the vision for everyone as well as create the action path for the other 2 points.

  • Pingback: 3 Prerequisites for Effective Sprint Planning i...

  • http://www.pmhut.com PM Hut

    Hi Tarun,

    #3 is a bit tricky. Some stakeholders will not even go to the meeting and many may have have not read the user stories. I suggest you have a mini-meeting involving the stakeholders explaining the user stories before the main meeting, this will solve the issue with some stakeholders not reading your stories.

    By the way, this is a good post, and I would like to republish it on PM Hut where many project managers will benefit from it. Please either email me or contact me through the contact us form on the PM hut website in case you’re OK with this.

    • Tarun

      Hi there,
      I agree that #3 is tricky but having yet another meeting IMHO is not a solution. What if they end up missing that meeting? I think as long as the team has a shared understanding of the vision of the project and feel that they are instrumental in realizing that vision then somehow they would pull through in every scenario/meeting.

      For some reason, if they haven’t read the user stories or can’t attend the meeting then canceling the meeting and letting the whole group know transparently of the reasons somehow manages to bring in the feeling of guilt. It then just propels everyone(especially the defaulters) to do the right thing and make progress towards shared goals.

      About reposting my post, it would be my privilege.