Spikes: To point or not to point...That is my question.

[Scott Theus]

Hi Everyone!

I think this is my first time posting in the community since the pandemic started, I'm looking forward to participating again.

There's some heavy debate in my organization around how to estimate spikes in a sprint: do they get estimated with story points or do they get timeboxed and overall capacity for the team reduced during the sprint? Ultimately it's up to the team and the scrum master to work out how they want to handle it, but my org is in the process of an Agile transformation and wants to establish best practices. 

Personally, I've never pointed spikes. Instead I work with the team to understand/confirm capacity based on  the number of people, how many points each can take over the course of a sprint, vacations, etc. Once capacity is known I ask the team to set a timebox for working on the spike and if that will reduce that person(s) capacity. (E.g. Two engineers are going to research the spike for 3 days and it is expected to reduce their capacity by 4 points each for the sprint.) I then use that to determine how much work the team can commit to for the sprint. 

The other option is, of course, to estimate the spike in story points like any other user story and include it in the team's load for the sprint. 

We've been discussing this quite a bit in my org, and for every source of documentation of "best practices" for one method there is documentation for the other. 

So what do you do for estimating spikes? 

[Erik Bjartnes]

Not sure about best praxises, but I would opt for scrutinizing how you do product backlog refinement. If the highest prioritized items in the product backlog are of high uncertainty, the team should set more time aside to refine the product backlog.  So basically timeboxing, but on the product backlog rather than timeboxing each item in the product backlog which to me seem tedious. 

I think a common pain point is often that the team is unable to reserve the reccomended "10 %" capacity for product backlog refinement, and rather prioritized all capacity towards the contents of the ongoing sprint. Caused by pressure to add more items to the sprint. But you get more issues when the drawback is a poorly groomed backlog as estimation, planning, etc. goes poorly.

Not sure if I like to introduce spikes as the way to mitigate the discipline reuqired to keep a properly groomed product backlog. Add fewer items to the sprint and reserve team capacity for backlog grooming.

[Omer Meshar]

My experience is that spikes and research in general is even harder to estimate than "regular" tasks, as usually you can spend more and more time on the research or POC. So instead of estimating spikes, we timebox them. We found out that usually a spike was considered successful after about 2 days of research, and therefor we scoped them to two days for the most part. 

[Bill Sheboy]

Hi @Scott Theus 

I have occasionally helped teams use the different definitions of "spike" described by Chris Sterling in his book, Managing Software Debt: Building for Inevitable Change.

• Research: gaining of knowledge to decide what to spike next, or to enable estimation in the future
• Spike: quick and dirty implementation to gain knowledge, and meant to be thrown away when done
• Tracer bullet: a very narrow implementation of part of a larger feature, built with production releasable quality, to enable estimation of the remaining work

To help with sizing, we discuss and decide: what is the question we are trying to answer?  That question will help us pick a type and to size only answering that question.  Follow-on work is another work item.

One other thing we use: not everything needs a "spike".  Helping people accept and become comfortable with ambiguity and uncertainty of product development can help.

Kind regards,
Bill