Professional Data Management

Oct 19
Let’s talk about Sprint Planning

The Agile Manifesto says that we value

Responding to change over following a plan

This doesn't mean that we should not plan at all. So we need to figure out how to plan the sprint without sacrificing our agile approach. Analysis paralysis is a well know side effect of the waterfall approach to software development. For the uninitiated Analysis Paralysis is an Anti-Pattern that refers to the idea that so much time is spent on planning that the entire landscape changes beneath our feet. To avoid Analysis Paralysis, the Scrum ceremonies, provide varying levels of granularity to ensure that detailed planning is only done just prior to actual implementation. The planning ceremonies are as follows:

Product Vision
This is the guiding statement of the project, the "elevator pitch". An eleven second statement meant explain the value of the solution and the problem it is meant to solve. Post it on the wall in your team's project area. Motivate the team

Product Roadmap
A high-level guide to the features to be implemented in each release. At what cadence will we deliver features.

Release Plan
More detailed plan for the features to be implemented in the coming release including additional prioritization of User Stories to be included in the release. Detail about what will be in the coming release as well as what stories will most likely go into each sprint until the next release.

Sprint Plan
The most granular level of planning done. Details of the task necessary to bring each User Story to its definition of done. This includes Evaluating Story Points and Acceptance Criteria provided by the Product Owner and defining Delivery Team Tasks.

A typical Sprint Planning meeting will be 2 – 4 hours for each week of the sprint. If your sprint is 2 weeks you will have a Sprint Planning meeting no more than 8 hours. The Sprint Planning Meeting is a good opportunity for Team Leveling exercises like Planning Poker to help the team come to a consensus as to Story Point Estimation. This is also a good opportunity to evaluate the Product Owners initial Story Point Estimations​ and Acceptance Critera gathered from the customer. Also during Sprint Planning the Delivery Team will expose the Delivery Team Tasks necessary to bring the User Story to the teams stated definition of done. In most cases the team will only be able to identify about 60-75% of the required delivery team tasks. The amount of effort required to realize the other 25-40% of the tasks is far beyond the value of being at 100% before the sprint begins. Any tasks identified in-sprint can simply be added to the task list for the User Story based on updates provided at the daily standup.

As a User Story begins to contain more that about 20 Delivery Team Task associated it becomes more likely that the User Story is so large and complex that we are missing important details. For example, if a process only has 2 steps it is unlikely that you will omit a step when describing or performing the steps. The same level of complexity can be applied to the collection of Acceptance Criteria. If we use a standard format like Gherkin, then we can easily keep the criteria simple and to the point allow for an even count. So a User Story that has more than about 20 Gherkin statements for Acceptance Criteria could be considered an Epic or Feature too complex to be completed in a single sprint.