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.