YDS: How Should a Scrum Team Handle SPIKES?

[@widowspider]

In my teams, we use spikes as a way to reserve velocity to do discovery work and planning for future backlog items. We've found them really helpful when we explicitly state their purpose, what the end 'deliverable' of the spike is (which is usually a plan for next steps that the team reviews, then scoping out backlog items) and account for the potential complexity of this learning work by estimating them. It's given greater visibility to the effort that this work requires and makes it a priority as part of our sprints. It has also pushed us to better document decisions and plans for transparency which was a major pain point in the past.

[@krod16]

We need to do spikes in our team because the software architecture is vast and time is required to investigate. We also need to use that time to check the impact any changes will have on other parts of the software. This can take several sprints. The problem is if we don't do this we risk doing the wrong design/architecture changes that will be expensive to fix later on.

[@matthiassuter1043]

If I understand you correctly, instead of saying, we need to learn something before we can start the story and will do therefore a spike you say, we will figure out everything we need to know within the context of the story. In my experience, spikes are normally done when a story can not be estimated because too much unknowns or can not be split in pieces enough small. So how would you go about this problem?

[@OskarPiano]

First thing coming to my mind is that it simply is not refined enough and so it can be taken once it's refined enough.

[@Ella-dd3vz]

In our team, Spikes are done as a knowledge acquisition activity done 1 sprint earlier than the actual user story as a preparation. So it has it's own acceptance criteria. But my dilemma is when they set a timebox but is not followed, because the acceptance criteria are still not met. I agree, the hot take on spikes as anti-pattern has it merits, but I think it is more applicable on mature teams.

[@OskarPiano]

The scenario described in the video (spike is asking for permission to learn) is one of possible scenarios and it is a anti-pattern. It might also be that the team has all the freedom to learn and they simply choose to organize their learning into tasks like spikes for e.g. better seeing progress for positive motivation.

[@neil1killick]

I don't see "spikes" as an anti-pattern, personally. I see them as a good way to manage both technical and schedule risk. Imagine a scenario where we are a development team in sprint planning, doing some technical slicing and work breakdown so we can plan how we will implement our chosen capability. There will sometimes be instances where instead of being able to say "let's implement X using Y approach", there will be multiple viable approaches, and we're not sure which is best at this time. So we want to explore those approaches, but not so much that we end up exploring for most of the Sprint (oh yes, this happens a lot). So we agree to a short time-boxed exploration, with specific parameters, which enables us to make a choice at the end of it. If at the end of the time-box we have not made a choice, then the implementation of X might need to be deferred. Another scenario is we have no idea of how to approach implementing X. In which case we need to incorporate some upfront research so we can ascertain our options. Either way, this is what a spike is, and TBH I think using them in the way described above is more likely to help us AVOID anti-patterns (such as analysis paralysis) rather than be one in of itself. As ever, YMMV.

[@RylinSlotterbeck]

A solid hot take IMO. Teams, and orgs, can easily fall into Spike Culture for fear of delivering the wrong solution. I know teams that leverage spikes as design delivery and then implement in a following Sprint. I ask why can’t that be part of the delivery (i.e. prototype).

[@OskarPiano]

I noticed that some engineers can put on them selves an expectation of a very certain and precise estimate. In that situation they need a lot of knowledge gaining for that certainty and precision. Obviously that is an unwanted approach. Usually it is good enough to explain them that thit high certainty is not bringing value of any kind and that with lesser certainty we still have predictability robust enough for planning a sprint. That is what counts and we can use that time and energy for other valuable good enough things.

[@paulcasanova4836]

Nice vid guys, thank you!

[@chihotdog1554]

How about this one, consistency reduces complexity, just add a buffer to every sprint for learning and that way it comes to be normal?

[@user-vk3xc8qs8n]

Great topic. An Agile coach, in my previous org, advocated for spikes. However, the team never used them. What they did do is try to allow for 20% of their capacity to be for innovation. I think they kept over-estimating how much work they could get done so I am not sure if that innovation ever happened. The developers were split across 2 major projects, and the ScrumMaster was a developer and a ScrumMaster for 2 projects. I suspect that made it hard to plan for innovation.

[@johnny2703]

Good explanation. I'm a Scrum student, it makes sense. Thanks.

[@phooey098]

Interesting "hot" 🔥 take. I need to let the idea of being an anti-pattern resonate after just teaching a group the other day about possibly using the SPIDR method to think about ways to split their user stories. However, I like what was said and that this is basically the Developers asking for permission to learn. Hmmm 🤔 the "PIDR" method...

[@TheChur]

Saving this one to watch later after the spike debates today 🙂

[@AgileforHumans]

Good to see you here @Matt! Hope this vid helps :) --Todd

[@archiee1337]

Should learning be taken into consideration while estimating, or we should reduce the capacity instead like mentioned in the video?

[@AgileforHumans]

Both? It depends on what you're SPIKING and how you've timeboxed the Spike. In general, the learning should be baked into the estimate.

[@KPkUnitedWeStand]

Hey guys I’ve had a scrum team who wanted to point the spike in a sprint for “visibility” I kinda pushed back about that it doesn’t bring business value and why should we even estimate point or it? The dev team insisted they need to? I then suggested let’s time-boxed it in hours or put a limit in days within a sprint the dev team all pushed back. What would you do as a scrum master?

[@scoogsy]

While this might be a hot take, and I can understand where you’re coming from, I was waiting for the “and this is how you tell people what we will do instead”. Telling people “drop spikes they are an anti-pattern” doesn’t help them. I get being honest with the product owner but I’m not sure how that conversation really goes. Is it “Hey we aren’t really sure how this will be implemented. We’ve got an idea on what we will do, but it might not meet our basic standards and we may just discard the approach at the end of the sprint. We aren’t even sure how far we’ll get through this.” it’s the difference between having a solid approach, but knowing you will run into unknown along the way, and going into completely uncharted territory, where you aren’t even sure what your approach will be, or if the selected candidate approach will be in principal fit for purpose. Is it saying to the PO that we don’t know how to do it, or how long it will take, but we are committed to the sprint goal, so we’ll experiment and see what happens this sprint? Then in review the team says that was a learning sprint, without any genuine expectation that it realistically could have been delivered upon, but we don’t call it a learning sprint, or a spike because those words are taboo? I need some direction here 😅

[@MrShairKhan]

Another great topic and I had to watch this video multiple times just scrum guide as this is something is happening in our team. It is making lots of sense. Instead of spike team can do a better refinement and break the story if needed. End of the sprint team has to deliver value...

[@archiee1337]

Isn't that a completed analysis brings value? 🤔

[@andrechristianto7131]

I have different opinion. But yes there are not many argument about spike. This is very interesting guys. My opinion spike could be treated like high level PBI,it need to be broken down and more things to do before it can be executed. It has similar attribute, has some value because it has direct/ indirect impact on product I believe, just like technical debt it still have value, and spike is appeared to be a signal of risk is involve in development. What do you think guys, i really want to dive deeper on this

[@rylandleyton669]

I think you still point them, it's capacity, and the PO gets to weigh in on the value of the information. There's an accountability piece here.

[@archiee1337]

How to handle tech debt then? Same, no direct value, same as for spikes/learning/analysis.. right? What about creating a technical architecture presentation for other teams? Also, no value from product perspective :)

[@AgileforHumans]

Tech debt is a little different. We should do a video...

[@chiefnase2471]

I agree, it's brings no value and should not influence the Velocity. You could have just spikes in one iteration with a perfect chart but still wouldn't have provided any value. Also planning, testing and figuring stuff out doesn't need to have another fancy name. Keep it simple

[@timwendt1935]

Can't agree with this one. Spikes absolutely have value! They generate knowledge to burn down risk and discover unknowns. Can they be misused? Of course, but that doesn't make them an anti-pattern. They are extremely useful as a way to constrain an exploratory activity to a sprint, focusing the team on knowledge generation and vet (or even form) a hypothesis. Very useful in environment of high complexity and can save the team a lot of rework down the road. The anti-pattern you should be wary of is committing to complex work with unknown unknowns.

[@gregmester3084]

Disagree with the hot take on spikes. I also disagree with the dev team having to ask permission, but yeah I understand on school says the dev team asks what do. I love spike to let team get a better understanding of all the unknown connection issues. The idea of a spike should be use to help time box something. The timebox is a good tool to provide boundaries. A spike is something that last a day or two, a focused effort to reduce risk around something. I don't like teams that say lets do a spike and take an entire sprint. I also believe it helps get away from the fall water mental of getting an entire complete product. It free up the mind from having to please someone else, it is just pure experiment. Now if the code works great then it can be use to deliver the value to the customer.