There are two distinct phases of sizing that can occur on your average Scrum project.
1. Sizing for release planning
2. Sizing for taking into a sprint
Both of these sizing activities is important and distinct from the other.
1. Sizing for release planning
The goal when sizing for a release is to get a gut feel of how big the release is in as quick a time as is reasonable / responsible. Activities such as Magic / Affinity estimation are invaluable as they allow a lot of stories to be estimated in a short amount of time.
The goal is not to lock down the sizing or to discuss the implementation or design in details nor to look for minor flaws – though it might be useful to point out obvious ones early. The main goal is to get a gut feel of how big this thing is in order to make some decisions and hopefully understand how long it will take if you start working. Sizing at the release level acts as an aid to help you keep sort of on track. My experience is that for 3-6 sprints of work this is good enough to deliver to.
Sizing for release planning is always on a good enough basis. The team will always be able to revisit the sizing once they have had a longer in depth discussion about the content in a grooming session or SP1.
2. Sizing for taking into a Sprint
The goal when sizing to taking a story into a sprint is to make sure the team understands the story well enough to confidently say that the story is a given size relative to any other story in the release. A key component of this sizing exercise is the conversation that occurs when the team sizes the story with Scrum poker. It is important for the team to have a conversation if there is a disparity in what each team member believes the size is so that the team’s knowledge and understanding can grow about the work they are about to do.
If an estimate comes from the initial release planning estimation – then resizing should occur when the conversation about the story has happened in grooming or sprint planning.
If the sizing comes from a previous estimate made in grooming or sprint planning then the size should only be changed when new information comes to light that effects its relative size to other stories. This helps reducing sizing churn as everything is relative to each other. Resizing a single story without any new knowledge would then affect other relative sizes which may have an unintended ripple effect on the size of the backlog that doesn’t make sense seems as it is all relative – and the velocity is relative to it as well.
If a team starts a story and discovers new work while working on a story that was not included or couldn’t have been anticipated in the sizing of the current story a new story should be added to the backlog to accommodate the new functionality. The story shouldn’t simply be resized to include the new functionality or delivered with the new unplanned functionality as both of these actions hide what has happened with the story and may lead to the story that was being committed to for the sprint not being completed. A new story will allow the changes to be tracked effectively – and planned for in the future. A new story will ensure that the team can continue to work towards the functionality it knows it is committing to in a sprint.
Metrics for planning the future
It can be interesting for the Product Owner and/or ScrumMaster to track the differences between the initial sizing made for release planning and the actual sizing once the conversation occurs for sprint planning. It can also be interesting to track the amount of work missed during the initial release planning. Both of these data points can help to inform future planning as to how much we usually change between the start of the release and the end. This could help increase predictability by allowing the planning to take this into account in the future if necessary.
Size early, embrace change late
Early sizing is great – but don’t over complicate it with trying to make it precise. Rather make it quick and good enough – then revisit it when you have the time for each story. Track the amount that you increase on average over time and use that to increase your predictability if possible rather than wasting lots of time upfront and fighting the change at the end.