Managing Uncertainty in Agile Projects using Spikes

Some product backlog items and user stories can be developed based on the shared understanding of the customer that the team and Product Owner already have.

Others cannot. We need to dig deep; we need to talk to real customers and users. We need to marshal all of our requirements development skills to create a new understanding of the customer’s need and make sure that our team internalizes this understanding in developing the product.

The challenge is often figuring out how to do this within our agile frameworks. If you have a two-week sprint, you don’t have time to take a week and a half to interview customers, analyze their input, model their potential solutions, and then convert everything into user stories and acceptance criteria.

But there are many ways to do this, and I’ll give you the best that has worked for me: using analysis spikes.

These are wooden spikes, helpful for killing vampires. Not typically encountered in agile projects.

What are spikes?

A spike is a to-do item related to research or other information development. Spikes don’t directly contribute to the product like user stories do, but they’re important work that still needs to get done.

When the team needs to figure out what kind of server to use, that’s often called an architectural spike. When the team needs to figure out which JavaScript API to use, that’s often called a design spike. And when you need to come up with a better understanding of the customer’s needs, that’s called an analysis spike.

Some spikes arise before the project begins…

We Business Analysts are accustomed to working in the “fuzzy front-end” of projects… those situations at the very beginning where we have high-level detail about what our customers and users need but little detail.

It’s helpful at this point to figure out what our epic-level analysis spikes are. For example:

• What is the business value of this or that epic?
• How sure are we that a particular feature is valuable?
• What are our customers’ expectations of a feature?
• What are our competitors doing?

It’s generally a good idea to add these spikes to our product backlog at the epic level. That way, we can understand the big questions to figure out, before they become either urgent or moot.

Some arise before a sprint begins…

If you have already started implementing the fantastic advice I offered, you’re starting to think more and more about the next sprint as your current sprint progresses.

While you’re getting a handle on the backlog items that will probably be assigned to the next sprint, start to look for uncertainty in those items:

• Are there any obvious holes in our understanding of the item?
• Can we create acceptance criteria easily, or are we making things up on the fly?
• Is the user feedback all pointed in the same direction, or are there differences among users?

These spikes are usually added at the user story level. These are not typically as urgent as the epic-level spikes, as they are more detailed and have more narrow impact.

And some arise during sprint planning sessions

Sprint planning sessions are where the rubber meets the road. If we have successfully identified and resolved our spikes, the session will go quickly and smoothly. But we can’t predict everything. Inevitably team members will have questions that no one can answer. In these situations, we have two outcomes:

First, if the new spike can be quickly resolved – by calling a customer or asking around the organization or doing some quick research – any dependent backlog items can be incorporated in the sprint. Often, however, the team will feel uncomfortable committing to functionality that isn’t well-understood.

In those cases, we simply add the spike to our product backlog, prioritize it appropriately, and resolve it before the next sprint’s planning session.

How do I effectively resolve spikes?

In agile projects, we don’t have the long requirement development timeframes common in waterfall projects. Instead, we typically have a week or two to reduce the uncertainty and complete our spikes.

Accordingly, we have to use the right requirements development methods. Approaches that take a longer time to execute (e.g. surveys, documentary reviews, reverse engineering) usually can’t be done.

Instead, focus on the basics. Have one-on-one interviews with customers. Observe them working with your product or similar products. Conduct quick focus groups where you can get the opinions of multiple users. Create rapid prototypes during your sessions with them to make sure you have the right understanding.

Above all, try not to get too bogged down in details. Remember that if customers don’t like a feature, it can be tweaked in future sprints to improve the product.

Wrapping Up

Analysis spikes are key to developing great products and managing risk in agile projects. If you’re not using them yet, start doing it today.

Subscribe