Spike/investigation story management
Hi Everyone,
I am interested to know how scrum teams manage investigation stories (aka spikes). Very often our PO requests a feature development/improvement that needs first investigation and then fix.
We usually either include the investigation story in the sprint and the fix in the next sprint, without giving story points to it but instead time-boxing (1 dev day) or reserve some time for possible fix of the outcome of investigation. so the question is: is that the normal way to include spikes into the sprint?
If a spike investigation is to help the team understand more about a Product Backlog item, shouldn't it be considered part of refinement?
Spike investigation is to help understand how x feature can be fixed (which will require devs to deep dive into codes).
during grooming we discuss the requirements (what should we achieve by fixing/developing it), so doing a spike duiring an hour grooming, will mean that someone from the team is focusing on spike while other team members are grooming another story...because the spike will need 1 max 2 devs to do it, so in this how should we go ahead?
We usually make a User story for the same, it is usually refined to define the expected outcome of the analysis and estimated.
Expected outcome could be following in our case:
- Confluence page
- Rough Split of the user stories if possible(not refined)
- Rough estimate for the required feature
In the end of sprint, we usually orgnize a small meeting to discuss the "Design approach" , estimates and split. If we are all aligned and PO agrees, we can then add user stories to the product backlog.
Spike investigation is to help understand how x feature can be fixed (which will require devs to deep dive into codes).
during grooming we discuss the requirements (what should we achieve by fixing/developing it), so doing a spike duiring an hour grooming, will mean that someone from the team is focusing on spike while other team members are grooming another story...because the spike will need 1 max 2 devs to do it, so in this how should we go ahead?
What you're describing is not consistent with how backlog refinement is described in the Scrum Guide.
It sounds like you are describing an event, or a meeting, for the team (or members of the team) to get together to do the work. However, in the Scrum Guide, backlog refinement is not an event - it is described as "an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items" that "usually consumes no more than 10% of the capacity of the Development Team".
Although getting people together to perform refinement is not only common and something that I've found useful, backlog refinement is not limited to this meeting. Individuals or small groups can go off and expend effort to perform refinement activities and then come together during refinement meetings to share what they have learned with the others towards the aim of understanding the items in the Product Backlog.
Something else to consider is that the "10% of the capacity of the Development Team" is not a timebox. Unlike other Scrum Events, the effort to spend in backlog refinement does not have a hard limit. It may be useful to generally plan for 10% of the team's capacity, but there may be cases where more effort, perhaps even much more effort, is required to ensure a good understanding of the Product Backlog in order to facilitate Sprint Planning sessions. The effort needed for refinement should be accounted for during Sprint Planning.
I may be interpreting your statements wrong but I really don't see a need for your team to be doing Spikes. Unless you feel that the investigation will take more than half the Sprint why create a time-boxed Spike? Why can't the Development team spend 2 days researching and then fix the problem over the next 2 days? That way they are still close to the problem, are focused on the area of code that needs to be addressed and do not have to context switch.
I advocate using Spikes to prototype or investigate only where there are significant knowledge gaps for the Product Backlog Item(PBI) in question. In these cases, there is not enough information known to be able to say the PBI is ready to be pulled into a Sprint. However we have on many occasions had a Spike in the Sprint, completed the investigation early in the Sprint and decided the PBI is now well enough known and that they fix could be done during the remainder of the Sprint. Conversations and negotiations ensue.
I feel that Spikes should occur infrequently. If I see a lot of Spikes I bring it up with the team and discuss if there could be a better way to refine the stories without the formality of creating PBIs.