Estimation sessions during sprint...
Hi All,
I was hoping to gleam a little wisdom from you all on here regarding time spent estimating during sprints. By this I mean ad-hoc requests for estimates/spikes for future backlog items.
Often during a sprint, we have requests from our product team to t-shirt size high-level stories for the backlog. These estimation sessions will include a varying number of developers and can last anywhere from 1-4 hours overall. This obviously impacts the sprint velocity and generally is an unrecorded drain of sprint resource.
We tried to manage this by spiking (and estimating) this sessions and together or reducing sprint capacity (by a set percentage to accommodate the sessions) but non it this feels right.
So my questions are:
- Should sprints accommodate ad-hoc estimation activities or should they be planned as spikes for future sprints?
- If they are spikes, should they themselves be estimated/timeboxed?
- How does everyone else handle ad-hoc estimation?
Any wisdom would be much appreciated,
Kind regards,
Wayne.
In the most general sense, yes, you should have time to perform estimation during Sprints. Even more generally, this is captured in the activity of "Product Backlog refinement", which the Scrum Guide defines as "breaking down and further defining Product Backlog items into smaller, more precise items". Part of refinement includes ensuring that the Product Backlog is sufficiently detailed, ordered, and sized. Previous editions of the Scrum Guide have used the word "estimate", but the November 2020 Scrum Guide now uses "sized". Also, previous revisions of the Scrum Guide have recommended allocating about 10% of the Developer's capacity for refinement, but this has been removed from the November 2020 edition to make it less prescriptive. I don't see why these ad-hoc requests can't be considered refinement since, depending on these high-level sizing activities, they may lead to a reordering of the Product Backlog.
The Scrum Guide has never described how refinement happens. Some of the teams that I've worked with preferred to make the bulk of refinement a team activity, scheduling time regularly. Other teams divide up the Product Backlog Items that need to be refined and only meet for short periods of time to synchronize on what is being refined and the current state of the top of the Product Backlog. I'm sure others will be able to describe several other methods.
As far as Spikes go, I tend to view a Spike as part of refinement. There may be some open questions about one or more Product Backlog Items with concrete questions to be answered or require a more significant dedication of time and effort from a Developer or the Product Owner. This more intense effort is captured as a Spike and planned appropriately, and the outcomes help guide further refinement. Examples of outcomes include user interface mockups, prototypes, one-page summaries, completing training or tutorials on new products or tools, and similar. The only guidance that I like to focus on is that a Spike should be completed within a Sprint. That is, it should be planned during Sprint Planning and the outcome achieved by the next Sprint Planning.
Between leaving room in the Sprint to ensure that refinement is happening and the planned Spikes, that covers anything that I've typically seen asked of a team to help ensure the Product Backlog's readiness. I'm sure there are probably some edge cases there, but having the team figure out how they want to approach refinement (including if and how to use Spikes) and ensuring some minimal level of refinement time each Sprint will go a long way.
Why is "ad-hoc" estimation being done at all? Isn't estimation being done in a managed way during Product Backlog refinement? Aren't the Scrum Team in control of refinement at all times, deciding for themselves what needs to be estimated?
What forces lead to a so-called "product team" into making these "ad-hoc" estimation requests?
Thanks you Thomas and Ian for your replies.
In answer to your question Ian, the product team are randomly requested by commercial teams & the business to size pieces of work. Arguably these could be planned for the next product backlog refinement session but are often raised in priority to be done within sprint. The outcome of these sizing/estimating sessions are to schedule/plan in future sprint and roadmaps. In some cases, if the estimate are too large, the work will be abandoned.
As I see it for us we have 3 options:
- Ensure all sizing is performed in the product backlog sessions (resist ad-hoc, in sprint sessions).
- Plan in spikes into a sprint to perform these sizing sessions (do we size the spike?).
- Factor into sprint capacity time to perform ad-hoc sizing (10%?).