One of the most common concerns amongst product owners and teams new to agile is the problem of what to do when no one in the team or the wider business know how to achieve something.
This might be a thing – how do we how do we add a new data point to and old customer data management system? Or something huge – how do we build a secure log in method using a new customer API endpoint?
A purist waterfall method can struggle with this approach – we need to know and plan everything prior to implementing anything in this process. This can lead to a lot of time, planning, discussion and contributing resource to no expression of actual value.
Scrum Agile proposes a different way of dealing with this in a way which allows for the tracking of progress, setting clear expectations on outcomes and keeping work inside a time based framework so that it can be managed against other priorities – a SPIKE ticket.
What’s a Spike?
a SPIKE, or Spike (I prefer the capitalisation to make them stand out as something different but this is semantic) is a mechanism proposed by Scrum for a type of investigation task which a Scrum team can carry out to better understand the requirements for a project.
They have become quite common in a range of different Agile environments to deal with novel, unknown activities.
They are most useful in new projects and when working with either older or poorly documented systems – the kinds of things where your development team simply isn’t familiar enough to come to a conclusion on a points score. The aim is to give your development team time to investigate an issue in order to provide additional information on a solution, allowing us to get closer to agreement on a solution and a complexity estimate.
The pointy end
Spikes and investigation tickets are quite common in Agile backlogs – you’ll see them relatively quickly if you’re spending any time with a backlog of items.
Despite their frequency, one of the biggest issues with Spike tickets are that they are poorly structured, which can lead to problems with implementation, expectation management, outcomes and a general eyerolling or feeling of dread whenever a Spike gets mentioned.
So, what kind of things should we look for to tell us that a Spike isn’t going to work, or hadn’t worked as well as it could have? Here’s a few things:
- Spike tickets lack sufficient information or structure
- Spike tickets are blank apart from a title or a single line “investigate x” style.
- What a Spike is trying to demonstrate is too vague.
- Open ended questions such as “how can we do x”.
- Ticket is written last minute in an estimation session.
- The Spike is considered a “nice to have” by the development team, product manager, scrum master or stakeholders.
- A lack of business facing acceptance criteria.
All sounds a bit like issues with a normal development ticket, right? That’s because it is. There’s precious little in how we should approach a Spike compared to a normal development ticket for your team.
So what’s the difference?
The only difference in expectation is the level of quality and the ability to put the work into a production setting.
A Spike in the truest sense is not a generic investigation. This is the way in which so many Spikes and teams can run into difficulties. A Spike should aim to answer or to deliver something specific, and normally that should be a proof of concept.
A proof of concept isn’t something thrown to a team to keep them happy, or to pass some time, or on a whim so that we can look like we’re trying to get somewhere when we don’t have a clue.
Your spike tickets are there to support the development time in better understanding a problem which they do not fully understand, but they are also in an Agile framework (which if you’re following along will be influenced by Scrum concepts), as a result the work which your developers produce should be potentially shippable.
Whilst the results of a spike are unlikely to lead to anything which can be put live immediately the work undertaken must be more substantive than a navel gazing exercise in which things are thought about, documentation is reviewed etc. without substantive output. This isn’t a cynical point on ensuring output (mostly not anyway) – we learn more by doing than we do by more passive processes.
As a result, the best Spike tickets contain a simplified set of requirements compared to a full user story task – just include the arts of the user story which directly relate to the areas which need to be investigated and ensure that it is clear that the work is proof of concept level. I’d expect you and your development team to have agreed what a proof of concept looks like well in advance of this, in the same way that you have a definition of done for a user story.
Building a Spike
So, how do we go about working out what should go into a proof of concept style ticket? And what happens when that doesn’t work?
First and foremost, the best spikes come out of heavy collaboration with your development team. That seems obvious from a theory perspective, but in the real world it can be difficult to get all the time you need to set up successful, in depth collaboration when your time has literally dozens of tasks competing for it.
You’ll know you’re making progress with this when your team start actively telling you that they understand your request but aren’t sure how to implement it. This is your opportunity to start creating a spike.
Discuss with them in detail what they aren’t sure about. Keep the scope as bounded as possible – more than one spike is acceptable. Remember this is much more on the “research” end of your work, and the time to implement is therefore less predictable, so don’t overdo the amount of work.
The issues which you identify with your developers should relate clearly enough to a given part of your user story – this may be an aspect which is quite technical, but your role is to bridge that gap between technical requirement and customer expectation.
Your spike ticket should cover highly simplified use cases with clear technical expectations added by developers where needed. Remember that tickets should be agnostic of who’s doing the work, so detail and context is key to them. Anyone reading it must be able to understand why it’s important to demonstrate the concept, not build an all singing, all dancing version of the work.
As far as estimations and getting it into a sprint goes – at this point it should be not different to your normal process – prioritise it appropriately.
Testing an demonstration is different. Spikes can represent a considerable investment of resource in learning, understanding and creating something which, when you get down to it, may not look particularly impressive to the untrained eye. Building trust with your stakeholders is vital in this situation – they need to trust you that the work is valid, useful and worth the time. It also requires your dev team to consider the broader context of what they’re doing and be able to communicate this appropriately to your stakeholders in things like sprint reviews.
Done well, spikes allow your team to move faster through understanding. They clear the way for complete items by investing in demonstrating that things can be done and moving forward from there. Don’t be afraid of them, but don’t treat them lightly either – they should have a clear outcome and agreement in demonstrable output to avoid navel gazing or the perception of lost time.
PolyArch Product Management 