Back to Forum

Managing Spikes

Last post 10:21 am January 27, 2015 by Cherylanne (Cherie) Mercer
3 replies
Cherylanne (Cherie) Mercer
05:54 am January 5, 2015

I need some insight and thoughts on management of unknowns/ spikes (both functional/ technical) please.

We have a project that is currently in maintenance stage, with mainly defect management & limited enhancements. We also have the challenge of multi location teams some of whom have limited functional knowledge of the product.

With this,
- development requests (both defect & enhancement requests) come in via HelpDesk/ Support, get logged and triaged (for accuracy, completeness) and then get moved into the PB, by the PO, as either a Bug or a Story.
- at the point of sprint planning, if the scrum team are unclear of the functional/ technical impact of the bug or story, the team create a spike and include in the sprint.

However, on analysis, I found that
- in most cases, at the end of the sprint, the investigation is inconclusive,
- the scrum team has resolved original spike ticket and created a new spike ticket for a subsequent sprint. This cycle has gone on for extended periods over multiple sprints.
- the main issues we have is traceability and ability to provide a projected solution/ implementation date to customers.

Some of the suggestions to overcome were
- to address traceability, if the scrum team has concerns at sprint planning, include the original development request in the sprint and record all updates & findings in that request
- ensure very strict time-boxing, if there is over spill, then run a technical triage across the development team to address such issues


I hope I have outlined the problem clearly. Please can I have your thoughts on the best management of the above?

Many thanks,

Ian Mitchell
04:49 am January 7, 2015

It sounds as though more backlog refinement is needed before work can be planned into sprints. Development Teams should not induct work into a Sprint Backlog if they are unsure of its scope, or their ability to deliver the corresponding increment as per the Definition of Done.

The scope of each Sprint may need to be reduced in order to accommodate these refinement sessions. In agile practice it is better to forecast (and deliver) a little, than it is to forecast (and fail to deliver) more.

Cherylanne (Cherie) Mercer
05:31 pm January 7, 2015

Thank you Ian, greatly appreciate your time.

I agree with you on the scope of the sprint needing to be reduced and yes there will be considerable value to a joint backlog refinement meeting. I will suggest this to the POs & Scrum Masters in the team. My role is currently in process with responsibilities to define/ review/ refine all process frameworks across product, project and development.

Thank you again for your time.

Cherylanne (Cherie) Mercer
10:21 am January 27, 2015

An update on this Ian.

I have had meetings with the PO team and the Scrum Masters in the respective teams and discussed your feedback and the value of running joint product refinement sessions. They will start these sessions from their next sprint and we meet again after 3 sprints to evaluate progress.

Thank you again for your feedback.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.