Sprint Planning Meeting – Introduction and Basics

If you follow iterations and sprints as part of your Agile Development Lifecycle, a key ceremony in Agile is “Sprint Planning Meeting” or also called “Iteration Planning” in other variants of Agile. Sprint in Scrum is a time period in which the team does whatever it can to develop software as per features/ requirements the team has committed to. A sprint or iteration is started with a Sprint Planning Meeting.

Lets say we are in the first sprint. The team would picks up “x”  [“x” requirements are selected through an educated guess] number of top priority requirements. A good project backlog would not only be prioritized but also estimated. The team totals the “relative estimation points” for all these requirements and that becomes the “velocity” of the team for first sprint. After discussing with the product owner, the team finalizes the requirements it would take up in the first sprint and the backlog roughly appears like this:

The team has committed to 20 points of work. As this is the first sprint, and the team has committed to the work more on an educated guess than exact science [and this would hold true for future sprints too], the team might need to take on more work [if they finish all requirements] or need to bump off some requirements [if they have taken more than they can handle]. The team will ask product owner as many questions as possible and they can think of [acceptance test cases/ test data/ UI designs etc] and give a final commitment before moving to Part II of the sprint planning session. In this session they take each requirement and break them into tasks and the team member voluneteer, discuss and self assign these tasks. A typical sprint backlog after this could look like this:

Hence, a sprint planning meeting is basically a communication channel for the team and the product owner to decide on what work the team should work on in a given sprint as well as the team doing some basic ground work on starting with a particular sprint.

It is important to emphasize here that in almost all Agile implementations, the team does not report to Product Owner. Both are independent yet important pillars of Agile/ Scrum frameworks. Hence, there are some rules of engagement which the team and product owner need to adhere to:

• The team would commit to work based on their understanding. Although, the product owner is free to ask the team if they feel they are under-committing or over-committing, there is no coercion available for the product owner. The product owner would not coerce the team into committing to more requirements than they feel comfortable with.
• The sprint planning meeting is a synchronization meeting for product owner and the team to decide what the team has to work on in the next sprint. However, the team can request product owner to be available during the sprint at regular interval [if they can sit with the team, nothing like it] to answer any questions or provide feedback – especially during the earlier sprints as the team would be spending more time understanding the domain, product, project, framework.
• The thumb rule for time to be spent on a sprint planning meeting is 2 hours for each week of sprint – 1 hour for discussion on requirements discussion and 1 hour for task breakdown.
• Finally, in Scrum at least and preferably in other flavors of Agile as well, once the team commits to the story – there would be no change: no change in development team, no change in the requirements and no swapping. However, clarifications can be provided. If the team and product owner is divided on whether it is a change or clarification, it is a change. This is done to maintain team focus on what they commit and get a rhythm going after a few sprints.

After the first sprint is over, and the team goes for second sprint planning meeting, the team has a better idea of know how many requirements they can commit to. This idea keeps becoming better and clearer with every passing sprint and sprint planning meetings would not have much of a discussion on whether the team has committed right or wrong [over or less].

Advertisement