How to estimate spike stories

Last post 04:57 pm June 17, 2019
by Timothy Baffa
18 replies
Author
Messages
02:00 am June 6, 2019

How to estimate spike stories:

 

My team is working on a spike story to determine the best approach to solve/implement a new technology in the upcoming sprint (s).

How do we estimate the spike story & should the estimated story points be included in the team's velocity?

03:13 am June 6, 2019

Isn’t the spike you describe helping to bring work to “ready”, and part of Product Backlog refinement?

03:50 am June 6, 2019

Ian

That's correct Ian...spike story is not delivering any business value in the current sprint , however it will help business delivery in the coming sprint.

Given that user stories are estimated on what is known at that time, complexity, relative stories in the past sprints. how is the analysis/POC/spike story estimated when there is no information on how complex this solution will be, we have not done similar POC in the past.

 

What factors are to be considered for extimation.

04:28 am June 6, 2019

Should a Spike even be estimated? Isn't the purpose of a Spike to find all that is needed to eventually estimate the actual story for which the Spike was created?

04:46 am June 6, 2019

Should a Spike even be estimated?

 

This is my point exactly. If team is spending time doing the analysis (could be a day or 5), that will have an impact on the team velocity (understandably will decrease from past sprints).

- Do we accept the decrease in velocity and notify (to management)

Or

- Make up a number to maintain the velocity (even though we are not delivering any business value as of now, however will help business delivery in the coming sprint(s))

09:19 am June 6, 2019

The Scrum Guide states that Product Backlog Refinement activities "usually consumes no more than 10% of the capacity of the Development Team". Personally, I encourage teams to use this as a baseline when planning their Sprints. Depending on the length of the Sprint, it works out to about 0.5 to 2 days per person or about 4 to 16 hours per person, but there's nothing that says that everyone on the Development Team needs to be performing refinement activities or how to allocate that ~10% of capacity.

I consider "Spikes" to be refinement of existing work in the Product Backlog - either decomposing it into developable, testable, deliverable work or adding additional details to existing work such that the end result is one or more orderable, estimatable Product Backlog Items. Therefore, all of the things I mentioned above apply to Spikes.

I'd also point out one of the principles of Lean Software Development - "Decide as Late as Possible". When you have open questions or things to learn, delay the decision making process as long as possible, right up until the last responsible moment. If you make decisions too early, you need to rely on assumptions that may not actually be true when you go to do the work. That could make the decision wrong and the effort spent to fully understand the problem, evaluate and propose options, and choose one wasteful. By letting time pass and other decisions to be made first, you naturally change the set of options available to you and can make better informed decisions.

04:47 pm June 6, 2019

My coaching on Spikes is that aren't pointed. Instead I encourage that a time-box be set.  At any point during that time-box the team can decide that they done enough.  If the time-box is fully used then they revisit the purpose and decide how to move forward. 

I advocate that Spikes are activities undertaken to vet the technology that the team considers viable to implement the solution. As such it is part of refinement.  As @Thomas pointed out per the Scrum Guide it should take no more than 10% of the development team's time. Where I differ from @Thomas is that I don't interpret that to be 10% of capacity for a single Sprint.  If the team can deliver a potentially releasable increment during a Sprint and do 6 days of refinement (inclusive of Spikes and actual discussions on the PBIs) then I see no problem with them spending that time. It provides value in the long run. 

05:24 pm June 6, 2019

Where I differ from @Thomas is that I don't interpret that to be 10% of capacity for a single Sprint.  If the team can deliver a potentially releasable increment during a Sprint and do 6 days of refinement (inclusive of Spikes and actual discussions on the PBIs) then I see no problem with them spending that time. It provides value in the long run.

I don't interpret the 10% to be a maximum cap, either. I see it as a rule-of-thumb. If you're not spending something close to that amount of time on refinement and understanding upcoming work, you're probably not spending enough time on that type of work to be prepared for upcoming Sprint Planning. Of course, the specific time may vary per Sprint and you may choose to spend much, much more time on refinement than the suggested 10%.

09:09 pm June 6, 2019

I encourage my teams to estimate any kind of work (spikes, release support, supporting other teams etc.) they do in sprint if it helps in better planning and it is worth to do it. This may help to avoid overcommitting. At the end estimates are to help in planning and it is not a measure of the value that is being delivered. 

If you are using story point estimation. You can estimate in a similar way how you estimate user stories. Team will estimate based on what they know.

09:11 pm June 6, 2019

Thanks @Thomas for clarifying. I've began to think that I was a bit alone on that one.  In fact, I am alone at my current employer.

09:16 pm June 6, 2019

I encourage my teams to estimate any kind of work (spikes, release support, supporting other teams etc.) they do in sprint if it helps in better planning and it is worth to do it. This may help to avoid overcommitting. At the end estimates are to help in planning and it is not a measure of the value that is being delivered. 

If you are using story point estimation. You can estimate in a similar way how you estimate user stories. Team will estimate based on what they know.

12:53 am June 7, 2019

If Spikes are time-boxed to a certain number of days or hours, don't you already have an estimate?  Why add a second layer of estimates with points?

01:29 pm June 7, 2019

In my opinion estimating the spikes may have below benefits.

  1. It will go thru refinement process and help all the team members to get onboarded with the intent of the SPIKE. I see team members doing more critical thinking when they have to estimate. It also brings more transparency.  
  2. It will help not to overcommit the work in sprint.  

Most of the times it can be guesstimate but done by team who know their work.  

03:10 pm June 7, 2019

Shouldn't Spikes be created as a result of refinement? And if so, shouldn't the entire team already know the intent and purpose of the Spike?  Spikes are for researching something to provide additional information and clarity to a Product Backlog Item which will be used for further refinement of said PBI. 

Time-box the Spike.  The Development Team should be able to determine if they are over/under committing even if they don't use story points as the measure. If you are relying entirely on story points to determine your commitment, you could see problems as you start to work on a new problem space because the work for that is not something for which they are familiar and your points will probably not be very representative of the actual work. 

01:39 pm June 11, 2019

Should a Spike even be estimated?

This is my point exactly. If team is spending time doing the analysis (could be a day or 5), that will have an impact on the team velocity (understandably will decrease from past sprints).

>>> A story marked as Spike indicates that it needs to be refined. Do you think estimating a spike will help in refining or just refining it to a level that it can be estimated will be helpful ? what is your current capacity spent on backlog refinement ? Would it help to increase it a bit to refine the spikes?

- Do we accept the decrease in velocity and notify (to management)

Or

- Make up a number to maintain the velocity (even though we are not delivering any business value as of now, however will help business delivery in the coming sprint(s))

>> How accurate you think your team's estimations are ?  Do you think velocity numbers in your organization are used for team's performance measurement ?

09:26 pm June 11, 2019

@SRIKANTH RANGA ROUTHU, In my opinion, Spikes should not be suffixed with the word "story" or "stories". Let's reflect on this... What is a story, specifically what is a User Story? What was the intended purpose of a User Story? We've grown accustomed to saying story for everything and I'll admit I was in the same place before.

My understanding is that a Spike is a research item which is time-boxed. The result of the Spike should enable a User Story to be more refined and to be in a Ready state. The use of electronic tools like JIRA perhaps forces the notion that anything and everything is a story (again we're omitting user from this).

Let's take an example. All I need to do is a simple singular task i.e. Upload data to the database. Isn't our normal approach in using these electronic tools to end up creating a story and writing something like "As a Developer, I want to upload data to the database, so that.....". Does this really make sense? Don't you think it adds unnecessary complexity and process? If we had the ability to just add this as a task, would you still call it a story?

Technically, estimating (in story points) a Spike makes no sense. Your mindset towards a Spike should be more on the lines of "Hey Team, I may need 10 hours to research how to do a particular task, Let's add this item to our Sprint backlog. Hopefully, this would allow me to get the answer to help us work on the Story #1234"

This is my point exactly. If team is spending time doing the analysis (could be a day or 5), that will have an impact on the team velocity (understandably will decrease from past sprints).

What is the real purpose of velocity? What would happen if velocity decreases?

01:02 am June 12, 2019

Thank you all for your valuable feedback on this topic.

From the above, it makes sense to time-box the spike/analysis to help the team get to a position where enough information is learned to estimate the PBI and be taken up in the next sprint.

Or as stated by the Scrum Guide, spike/analysis could be conducted as Product Backlog Refinement activities (~10% of dev team)

@Steve Vb

Even though the company I work for has moved to "Agile" a while ago, some things are still micro managed by the management unfortunately.

ex:

- Every item that a team works in sprint (story, spike, prod support, etc....) has to be in Rally (ALM) and estimated

- Decrease in team's velocity should be explained in details 

These things will only change with proper education/knowledge and change in mindset I guess

10:56 am June 12, 2019

These things will only change with proper education/knowledge and change in mindset I guess

>> I second your thought , think about conducting a training for management on Agile. May be they don't have clear understanding yet. 

Decrease in team's velocity should be explained in details

>> I see velocity as the assumed forecast made for a PBI which is not the actual efforts the team might need to make the PBI as Done. So, what benefits your management will get from the answers for the assumed efforts ( a non real value). But this again will be solved only if they are properly onboarded on Agile.

04:57 pm June 17, 2019

- Do we accept the decrease in velocity and notify (to management)

Or

- Make up a number to maintain the velocity

Is the goal to learn something through the time-boxed execution of a spike, or to artificially "game" the team's velocity metric to appease management?