In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen – and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals – and asked for a time frame for when most of these would get done.
The agile ceremonies – especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and stories inadequate to estimate as they are used to doing at the sprint planning
Usually, stakeholders outside of the team just want the teams to be predictable over a reasonable time-frame, may be 3-4 months. This is a valid ask. However, teams struggle to deal with ambiguity and provide this guidance as part of their work. This causes immense frustration all around.
This is the place where release planning is most helpful. And more importantly this is the place where relative sizing is relevant.
Relative sizing – the act of using one story against which other stories are sized is used at release planning to set a rough guidance about the size of work and at arrive at an initial planning based on what pace the team thinks it can go – over few months. At the release level, the sizes (estimate) take in to account assumptions being taken and potential outcomes.
Once a team plans for a release – the need to size a story should not be there (unless something totally new comes up).
After a release planning is done, sprint planning can start focussing on the next natural level of detail. During sprint planning, stories refined for the sprint can be tasked and estimated. Stories, whose tasks, the team feels can be completed within the sprint can be the commitment to complete during the sprint. This commitment must also take into account available capacity in that sprint. There may be stories that team feels they may start but not finish – those are stories that are not part of the sprint commitment.
This way the team can focus on completion. Velocity becomes emergent.
Over a period of time, teams will find that predictability is valued – allows stakeholders to expect and react better. In summary, these are my suggestions:
- Adapt to ambiguity; use relative sizing to plan at release level – not during sprint planing.
- During sprints, focus on tasks needed to complete a story, estimate them and review available capacity (in hours). This will let velocity be emergent and taken with appropriate context, may be useful for longer term planning too.
