You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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?
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.
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.
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.