Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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

Scott Theus
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 20, 2022

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? 


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.

Like Scott Theus likes this

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. 

Like # people like this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 21, 2022 • edited

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,

Like # people like this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events