Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

About Spiking on Unknowns

DZone's Guide to

About Spiking on Unknowns

Agile works really well on things that you've done before — but how well does it work on things that you have never done?

· Agile Zone ·
Free Resource

See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.

As an Agile developer, I often start projects without a clear sense of exactly what I’m building. This used to be very difficult for me. I wanted to start with a complete specification for what I was to build, but today I know that it’s more efficient and effective to discover exactly what needs to be built just in time.

However, this sometimes leaves me with a set of unknowns in my critical path, like boulders blocking the road in front of me, that have to be addressed before I can move forward. These unknowns can be anything from how an API behaves to finding a framework that does things I need to have done.

That’s OK, though. When I find an unknown in my critical path, I simply spike on it.

Spiking is when one or more team members focus on answering one or more questions within a given time box. The goal is to answer the questions before the allotted time expires. If I can’t answer the questions then I’ll try to answer at least part of the questions and formulate a plan and timeline for answering the remaining critical parts.

I find that spiking on unknowns is an invaluable practice during iterative development. It’s easy to get lost in the weeds, especially when you’re doing research. Having a defined goal within a fixed period of time can be very helpful. When the time expires, I check in and see how close I’ve come to answering my questions. If I got satisfactory answers, then I move on. If I still need to do more research I will set up another spike.

Spiking on unknowns ensures that I don’t get lost for any length of time. I can always step back and reevaluate. Sometimes 80% of the resolution is sufficient and I don’t have to go for a total solution. Using time boxes to check in and evaluate my progress has become a useful practice that I have extended to many areas of my life.

If you hang around my office for any length of time, you’ll probably notice a Pomodoro timer going off every 25 minutes. Every time the timer goes off, I stretch but I also check in with myself and ask myself three questions: What have I learned? Where am I stuck? What am I going to try next?

Unknowns are only scary if they catch you off guard. Spiking on unknowns is a way to prepare and address issues before they come up. Generally, my spikes are anywhere from a few minutes to a few hours, but I have spiked for several days in the past. I try to keep my spikes as short as possible because this gives me more opportunities to check in and evaluate my progress.

The key to a successful spike is to have the right questions to research and enough time to get good answers.

The Best teams run on Jira. Here's how teams at a few of the world's most recognizable brands are teaming up in Jira to build great software that users love.  Learn More.

Topics:
agile ,unknowns ,agile implementation ,spikes

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}