Skip to main content

Spike in Scrum?

Last post 05:28 pm February 23, 2021 by Stanislav Ivanov
8 replies
05:59 pm October 24, 2018

Hello Scrum community

Scrum Guide says "The Product Backlog is an ordered list of everything that is known to be needed in the product."

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases."

Given this definition there could be no Spike in the backlog according to Scrum, is it right?

Should I evaluate different frameworks and build different prototypes (some of them could be thrown away), how could a Product Owner manage this need?

Thanks

Marco

 


06:42 pm October 24, 2018

Why would the evaluation and prototyping you describe be necessary? Would it be done in order to refine items on the Product Backlog?


09:25 pm October 24, 2018

What has been working well for us is that the BA and PO review any new item the second it gets added to the Product backlog.  The BA (me) identifies any likely place where the story is unclear or needs to be fleshed out and gets the necessary information to create a set of Acceptance Criteria.  We then do a formal grooming session where the developers review the story and decide whether or not it's ready to be worked in a future sprint.  Since we aren't working on a single product but rather maintaining a set of applications and tools, this seems to work fairly well.  

If I notice something is going to need additional developer time to research methods or go through code, I raise that to the PO and the team.


08:40 am October 25, 2018

Thanks Ian, thanks Larry

Should you decide to move your infrastructure to the cloud, you need to evaluate some suppliers (AWS, Azure, Google,...) and do some tests/prototypes.

The same applies when choosing a big framework.

It would take some days.

@Larry, your solution is smart and perfect for relatively small items.

How would you approach such a big activity?

Thanks

Marco

 

 


02:03 pm October 25, 2018

Myself I would break it down into stories and then add the stories to the backlog.  Do the same process as you would for a normal story in trying to get as much information up front, then review with the developers on what information they need to do the work.  The work may not be development of an application but instead the research and testing required to make a decision on which platform to use.


07:28 pm October 25, 2018

Myself I would break it down into stories and then add the stories to the backlog.  Do the same process as you would for a normal story 

Agreed, developers can help a lot here to break down the stories and tasks for PO as are more technical things.


07:40 pm October 25, 2018

I encourage my teams to not put Spikes in the Product Backlog.  Instead, I encourage them to put Spikes directly into the Sprint Backlog.  And that only happens if there is something that is blocking the team from being able to understand something in the Product Backlog.  By doing this I have found that they want far less Spikes and will instead lean on making stories more focused (or smaller if you prefer) so that any unknowns that are encountered can be dealt with as the information is found.  

Remember, the Dev Team forecasts a sprint backlog based on what they know at the time of planning. If they uncover something during the sprint, they inspect and adapt. If the sprint backlog needs to be changed, you determine if that change endangers the sprint goal.  If so, conversations occur with PO to rethink. If not, compensate and move along. 

My experience has been that teams tend to use Spikes as a way to thoroughly create specifications (old way). Much of the agile varieties actually encourage you do things without knowing everything. That is the where agile excels and allows you deliver incrementally.  Too many spikes sounds and smells a lot like waterfall to me. 


05:30 pm January 17, 2020

@DanielWilhite I'm with you. Too many spikes sounds like waterfall to me too - otherwise, we will need a new Kanban to control spikes only.


12:02 pm February 23, 2021

The updated Scrum Guide says: "The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

I believe Spikes match this definition as they help to make informed decisions on what can hugely affect product development in future.

However, there should be a good balance between Spikes and decisions which are made during regular feature development.

Decision to follow Spike approach should be agreed with the whole team and good reasons for doing this should be provided.


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.