Are Spikes are user stories or Epics? Can we have burn down tasks for spikes?
We are scaled agile team, where one team sits in Russia and other two in US & India respectively. We are having backlog grooming session for future sprint on 2nd week of current sprint where we do discuss on the stories which the PO brings in after discussion with stakeholder parties.
One thing I observed was there were couple of User stories created as spikes with a user problem and the acceptance criteria talks about the technical approach. This user story had only development tasks and the PO advised not to have QA Task as this will be sliced down to ready item for next grooming session and only developers estimated this user story. My understanding is that Spike is created to address the question but not to provide the potential shippable product. Please clarify on the below points.
1. Are Spikes are real user stories ?
2. Do we need to have drilled down tasks for spikes ?
3. How many spikes can we accommodate in a sprint as per standards and what will be the outcome in sprint review meetings.
Thanks much!
Aditya
My understanding is that Spike is created to address the question but not to provide the potential shippable product.
That is the way I interpret spikes but remember that the Scrum Guide never mentions how Product Backlog Items are defined. User Stories, Spikes, etc are taken from other agile practices.
Given my interpretation I coach that a Spike be time-boxed in hours and not estimated. I encourage the time-box to be less than 4 hours and is worked in one block of time instead of spreading the work out throughout the Sprint. Since a Spike is more like a research effort it is near impossible to task them out and most of my teams see no reason to do so. In fact they tend to get much better results when instead of tasking out a Spike they all swarm on the effort.
How many spikes can we accommodate in a sprint as per standards and what will be the outcome in sprint review meetings.
There is no such things as "per standards" in Scrum. The answer to the first part of your question can only be answered by the team. The second part of your question can be answered by understanding this from the Scrum Guide.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
Hello,
Spike is a term that comes from the Extreme Programming (XP) practice. You can use it to reduce the risk of a story or to facilitate the estimation of that story. It's not about writing code. The spike can be a series of investigations centered around finding solutions to one or more problems. That is why the PO and the development team shall be agreed for a maximum amount of time (3 to 6 hours maximum imo).
The Scrum team defines one or a couple of objectives for your spike. It is time-boxed even if you don't reach all your objectives. But at the end, you have a better understanding anyway. It is always valuable and you have reduced the risk of false assumptions. A spike is like an investigation by one or two developers.
It is a story to be prioritized and scheduled by the PO like any other story (without story point, just a time-box).
How many spikes can we accommodate in a sprint as per standards
A team may reasonably allow up to 10% of their time during a Sprint for Product Backlog refinement activities, by means of which work is made “ready”. Isn’t that what you are effectively describing?
Thanks @Daniel @Samuel and @Ian for your valuable inputs.
Cheers!