Do spikes need to be demoed or you kind of just describe the knowledge gathered from the spike.

During a Team Demo in safe. http://v4.scaledagileframework.com/team-demo/

Looks like the team could. But how do they do that. Technically the software solution did not change.


In Scrum, at a Sprint Review, "you inspect the increment and adapt the Product Backlog". Spikes (which aren't even defined in the Scrum Guide) are a method to capture things that your team needs to do in order to investigate, learn, and be able to deliver a Product Backlog Item in the current or future Sprint. There's no stakeholder value being delivered by completing a Spike.

Typically, there is nothing to demonstrate in a Spike. You haven't done anything to the project that you are working on. If anything, you may have completed a prototype or mockup. But you wouldn't want to demonstrate that at a Sprint Review for fear of giving the impression that there has been more work done on the design and development work for the Product Backlog Items.

Any completed Spikes are useful in the Sprint Review, however. Part of the purpose of the Sprint Review is to revise the Product Backlog. Based on the Spike, you have learned information about one or more other stories which may have led to additional detail being added, stories being decomposed.

So, no. You do not include Spikes when reviewing the work that you have accomplished in the Sprint. You may want to mention that you have done certain Spikes to better understand particular work, but that's about it.

Note: This answer was originally written against Revision 1 of the question. This revision only contained tags referencing and . The information regarding SAFe was added in Revision 2. This answer is based on my experience with Scrum and Disciplined Agile Delivery and not SAFe. SAFe does have guidance on Spikes that, to some extent, disagrees with this answer.

  • @otc Sorry about that. I added some stuff - I was distracted when writing the answer and pressed submit before I was totally done. – Thomas Owens Aug 18 '17 at 17:04
  • Cool, looking at Safe looks like they demo the spikes v4.scaledagileframework.com/team-demo But getting a mixed message accross the internet. – otc Aug 18 '17 at 17:21
  • @otc You tagged your question with scrum and did not mention SAFe. I can't speak to SAFe. But, like I said, Spikes are not a traditional part of Scrum (not mentioned in the Scrum Guide), but based on how people tend to use them (and how I've used them), I've given a good practice based on the information that is available in the Scrum Guide. If you want an answer in the context of SAFe, you need to specify that. – Thomas Owens Aug 18 '17 at 17:23
  • Cool thanx updating. – otc Aug 18 '17 at 17:23
  • Sry did not know if it mattered, thank you for the details. they look good. – otc Aug 18 '17 at 17:26

I disagree with the other answer given. The Scrum Guide simply says about the Sprint Review: "During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint." The goal of this event is to collaborate between the team and the stakeholders or users in order to get feedback and determine the next step forward.

While some spikes may not be appropriate to share because they might make no sense to the stakeholders, many are. Here are two examples I've experienced where it was clearly valuable to review spikes:

  • The team was evaluating two options for CMS plugins to support a feature. As a spike, they created two new throw-away screens that implemented the basic functionality of the plug-ins. They were able to share with stakeholders their recommendation based on ease of implementation and the stakeholders gave feedback on which prototype gave them the look and feel they prefered.

  • A team was working with a new API. We created a little script that connected to the API pulled some data. We reviewed this with stakeholders in order to validate that the information we were able to retrieve from the API was the correct information that they needed for their purposes.

Part of this also comes when planning the spikes. Often time there are ways to approach the problem that offer no opportunity for stakeholder feedback and ways that offer a lot of opportunity. I personally always favor the 2nd option if the effort is similar.


A spike is an experiment, so the expectations vs the results should be demonstrated, if not via a demo, via a:

  • a benchmark comparison
  • a competitive analysis chart
  • a design document
  • a flow diagram
  • a screencast
  • a burnup chart
  • a QA/QE test plan

The output of a spike is demonstrable, both to the team and to any other stakeholders. This brings visibility to the research and architectural efforts and also helps build collective ownership and shared responsibility for the key decisions that are being taken.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.