SCRUM Sprint Planning Gone Wrong

One of the things that is a hallmark of the SCRUM method of Agile development is that you have a unit of time during which you commit to accomplishing some amount of work before that unit of time has elapsed. In order to commit to how much work should be accomplished during the “sprint”, all members of the team meet at the beginning of each sprint for a sprint planning meeting.

The purpose of a sprint planning meeting is to estimate the difficulty and complexity of completing each task that is in your list of potential work items. At the end of sprint planning, a subset of these items will be picked as the set of items that the team commits to completing by the end of the sprint. While this all sounds straightforward and simple to most people, I have been in some sprint planning meetings that lose their focus.

Since there are typically quite a few items to estimate during a sprint planning meeting, time spent discussing implementation and testing details should be kept to a minimum. The SCRUM Master is responsible for ensuring the meeting moves at a reasonable timeframe so that the sprint planning meeting does not exceed the scheduled timeframe, typically 1 hour.

There have been several sprint planning meetings I have attended that had members of the team determining how the issue would be resolved during the meeting, instead of just estimating the difficulty and complexity of the task. It would not be unusual to still be discussing the merits of the first task more than 30 minutes into the meeting. Unsurprisingly, the projects this team was supposed to deliver were always behind schedule if they were ever considered feature-complete.