The approach most Agile teams use to get analysis done is to use a task called a spike. This allows a team member to do some deep dive work to prepare a user story.

There can be a lot of analysis required to get a user story agreed with the business users and adequately prepared before taking it into the sprint. This analysis needs to take place in parallel with existing sprint work, test support and all the other parts of a busy Agile team member’s daily life.

Spikes can relieve some pressure from the team by being a definite sprint deliverable, that also acts as a dependency for the user story that must be completed before work can start on the story. This can be made clearly visible to project managers on the backlog.

Spikes can also be abused. If a spike is too vague, or ends up eating more time than was originally planned, then it can be a hindrance to progress. Sometimes the scope can be too large to be completed in a sprint and only adds to the pressure the team feels.

The key ingredients of a spike are that they are:

• time boxed
• short
• clearly defined in terms of the output required

You could also say that there are usually no story points gained by completing spikes. They do not increase the team’s velocity.

Spikes can remove the pressure from a team by giving space to come up with the answers raised at grooming sessions. The work can include technical investigation of code or data, reaching out to vendors to confirm capabilities, having workshops with users to bottom out requirements, and many other activities.

The important thing is that they have clear goals, such as validating an assumption or doing the design work for the proposed solution.

QAs can get involved in spikes also, taking time to add detailed conditions of satisfaction for a complicated change and taking time to talk to the users to ensure the requirements are understood.

It’s important not to allow spikes to overrun on the allocated time. Since they do not contribute directly to velocity, the sprint will suffer if they occupy too much of a team’s time.

If the work is not or cannot be completed, report back to the scrum master or the team. If necessary raise a further spike for the next sprint to continue the investigation.

How much time should a team devote to spikes? It’s a good question. In order to keep the quality of user stories high, a lot of preparation is required (see my recent post on Agile Analysis). Allocate too much time to spikes, however, and you risk delivering less or no working software at the end of the sprint, reducing the velocity of the team.

It depends on the nature of the changes coming through. Reserve them for times when a story’s solution is not obvious, or there is a difficult choice to make between different technologies. Give a team member time to investigate the options, or to come up with the right solution.

If your backlog is looking light on stories that the team can start on immediately, filling up the space in a sprint with spikes to complete any missing requirements may be a good plan. For a sprint or two, the balance can be heavier towards spikes until the backlog starts to look healthy once more.

Spikes carry their own risks.

You may give too little time.

This can cause problems if the user story has a hard deadline. If a spike has not answered the questions but the story is due to be worked on next sprint, what should you do?

If this gap was discovered early enough it may be possible to extend the time, but something else in the sprint will necessarily be affected and need to be removed.

The team member does not document their findings.

This is frustrating when it happens. The output of a spike should be to bring clarity to a user story. Sometimes the investigation can uncover things that do not relate to the user story but are worth documenting.

I encourage team members to create a new page on our internal wiki, which uses Atlassian’s Confluence, when starting their spike. This allows them to collect all relevant and edge information in a forum where other team members can comment directly on the page, giving feedback or asking for further elaboration.

Writing things down makes you put more effort into getting it right. If you have to teach something, to play back the idea to peers, it forces you to think through it to a deeper level. This is a skill that is worth cultivating in your development team.

The story will be delayed at least one sprint, possibly more.

Quality takes time. It is important to explain to the Product Owner why the spike is necessary. They may not understand the details, but they will appreciate being included in the conversation.

Any impending deadlines will need to be identified to properly plan the investigation. One key question I ask is, “When does the change need to go live?” With that information the team can decide if it will fit into the release schedule or will this need special treatment.

The answers feed into whether there is enough time for a spike and the relative priority of them to other sprint goals.

There are no clear requirements on the spike

Just as I believe that each user story should be clearly documented, so should the purpose of a spike. It is worth taking time (a lot less time than for a user story) to document the details thoroughly and to ensure that they are understood before commencing work.

A spike should result in some form of output. This could be documentation, as mentioned above, answers filled in directly on a user story, conditions of satisfaction filled out and agreed with users; anything really. You just have to be able to know when you have finished.

We sometimes have a spike to allow a developer to try out a new library, or to build a prototype. The code is not intended to be merged back into the code base, it is more to prove a concept or help to finish a design document. There should still be some output, even just a few code snippets with some commentary.

You don't get an increase of velocity

Spikes do not carry story points and so do not contribute directly to velocity. I mentioned some of the benefits that doing sufficient analysis upfront can have in Agile Analysis. I hope it helped to show that by having complete analysis before beginning a user story, its development goes more smoothly and there are less surprises.

Spikes play an important role in filling out all the details and therefore have an indirect impact. Better quality in user stories before starting them should allow smoother development, with less issues and delays, and more user satisfaction.

The spike is not treated as a sprint priority

We use Atlassian’s JIRA as a scrum board and one failing is that while it shows user stories nicely as swim lanes, tasks (which my team uses to represent spikes) and bugs are all bundled into a single swim lane at the bottom. This gives the impression that they are of lower priority than the user stories.

This is not always the case. It often needs to be highlighted at a stand-up that the spikes need to be worked on before opening new user stories. A good team culture is required to keep the top priority work always to mind.

Conclusion

Spikes allow space for teams to do in depth analysis and design that goes beyond what is the normally possible for a scrum team given their other day to day responsibilities.

They need to be carefully planned so that a delivery date is not impacted. The spike must answer all questions at least one sprint before the work on the user story commences.

Make sure that you know when you’re done. If it is clear and obvious that the work is complete early, stop. Give the time back to the sprint. Clear requirements will keep the spike inside the time estimation.

Keep it time bound. If the spike slips over, re-assess. Ask

• what has been documented so far
• what is left to do?
• who needs to be involved, e.g. someone with more experience?
• how much longer will it need?
• what is the associated user story’s deadline?

Resist any attempt to extend a spike if the work to date has not been documented. Ask the team member to complete this and also to write a justification for extending the time on the spike.

If using spikes, encourage the team to begin writing a wiki page or blog post as they begin the investigation. Sometimes seeing what was tried, but did not work can be of benefit, and at least the documentation will not be forgotten.

Activities

If you use spikes, review a recent completed spike and answer the following questions:

1. Can you find the documentation from the spike easily?
2. Does the documentation include a recommendation?
3. Was the output reviewed by the other team members and accepted? Was feedback requested? Were there helpful comments?
4. How close was the elapsed time to the original estimate? Did it go over or under?
5. Was the spike acted on at the appropriate priority level? For example, if it was high priority, did it get picked up early in the sprint rather than being left to the end?

If you don’t use spikes, try these questions:

1. Can you identify a recent user story or bug fix that your team worked on but that overran the sprint (or even through multiple sprints)?
2. Did the story lack any analysis? Did this contribute to the delay?
3. Would a spike have been of use to try to bottom out the details before committing to complete the story in a sprint?
4. Identify an upcoming user story that is missing some details. Would a spike enable the analysis to be completed sooner than trying to fit the analysis around other scrum work?

Experiment with using spikes. Find out what works for you and your team. Write a blog post and send me the link; I’d like to hear how you got on.