This blog is more to share an observation and get inputs from as many folks as possible on sprint planning:
Often, teams do their sprint planning in the following way:
1. There are a set of stories (mostly) ready for an upcoming sprint.
2. Hence, the teams estimate their stories to pick a few stories from the backlog
3. The team uses story points – adopting Fibonacci series (I have not come across anything else!)
4. They may play planning poker, or, someone from the team proposes a number.
5. The team estimates stories and then pick stories until their velocity is reached.
6. Their velocity is the number that they have completed – could range from just completing development to some stories actually seen by users. For new teams, velocity is a number that the team may find reasonably impressive enough to tell outside.
Many teams that follow the above routine (or its minor variations) have been exposed to some form of Agile practices. Teams that do this, feel they are just following a routine and struggle to answer the following questions:
1. Why plan for the sprint?
2. What do the teams expect to do with the sprint plan?
3. And, Why ‘estimate’ the stories?
If you are looking for ways to re-boot your planning, consider the below
1. Focus on a key goal for the sprint:
The purpose of sprint planning must be re-focused to identify the value provided to the user at the end of a sprint.
Sprint planning, then, can identify tasks that need to be done in the sprint to provide that value to users. The value could be stabilizing a feature that has lots of bugs, or developing a functionality that users will like providing feedback on. Without an overall goal for the sprint – the sprint planning process will start weaker.
2. Keep your planning appropriately light:
Any planning activity is to understand the approach to a project over a given time frame along with constraints and dependencies.
Over a shorter horizon, as in sprints – teams can easily list down items they are uncertain about, get clarity and re-plan (or) if there very little uncertainties – use their prior experience to task out and review how many of the tasks – and hence the stories will get completed to meet the goal.
Focussing on story points and ‘estimating’ may actually weaken our view of the goal for the sprint. Understanding the sprint goal helps us limit or prioritise work that we do over the sprint.
3. Try different approaches to forecasting your team progress – including story count:
Much has been written about story points, relative sizes and estimation scales. When done as intended, they are reasonably good to forecast. All of them are meant to reinforce adaptive planning.
Try out different approaches to forecast your work progress: Understand your estimation scales better, including factors that influence your story sizes. Discuss why S-M-L, or 1-2-4-8, or Fibonacci.
In that context, story count is as good a measure of forecasting progress as relative-size based burn-ups. Story count is simply the number of stories the team manages to complete in a sprint.
Teams, that adopt story count gravitate to similarly sized stories in a sprint over a number of sprints. These teams, seem to focus their backlog grooming activity on creating smaller story sizes that the team can finish – say a story or two at least per person in the team.
Remember,
Relative sizing of stories becomes important when the team needs to provide some guidelines on how many sprints they think they will take to complete a project. In this case – they will need to adapt their planning for medium to longer term via release planning.
Longer the time-frame, multiple factors of technology, people, dependencies, uncertainties will need to be thought through. Hence, teams do relative sizing, identify completeness and certainty factors along with areas where they need more information to plan their release.
However, at a sprint level, and in teams that have a backlog not fully visible – lighter weight approaches to sprint planning may bring life back into your sprint planning process.
