During Sprint Planning or even while developing a large backlog of epics, there will eventually arise requirements that require some specialized skills, such as architecture, design, user experience (UX), etc. However, these items are not ambiguous of their true value or acceptance criteria. So how should these items be handled in a Sprint?
A Spike is time-boxed technical investigation to produce an answer in regards to some acceptance criteria on a PBI prioritized in upcoming Sprints. It’s a great way to mitigate risks early and promotes fluid iterations later in the project. It allows the team ascertain feedback and develop an understanding on an upcoming PBI’s complexity.
Spikes should be estimated as in-Sprint tasks during Sprint Planning. The task’s duration should be spent researching and developing some ‘thing’ that can be delivered. That thing can be a working piece of software, UI screen, UX workflow, documentation, etc. Ultimately the value from the spike is a direction or re-direction in the course of the project. If the team estimated that a Spike takes four hours, then ONLY four hours should be spent researching or developing. A Spike is not completed after the item is done, but rather as soon as the time is up. Prototypes, Proof of Concepts (PoC), and Wireframes all fall into the classification of Spikes.
TO SPIKE OR NOT TO SPIKE…
In Agile software development, the architecture evolves to meet the needs of the PBI’s forecasted in the given Sprint. It’s lean. Unlike a bridge or a skyscraper, developing business software does not necessarily require all of the architecture defined upfront. It may be necessary to Spike on the best persistence option, but the implementation of it should be wrapped into a PBI.
Through the Scrum projects I have consulted on, I’ve found that building UI wire frames are perfect Spikes. This gives the stakeholders an opportunity to review upcoming screens and provide feedback on the design, style, and workflow. Subsequent sprints are smoother for the implementation of those screens. However, as the project progresses, there is a deeper understanding of the style and design of the application which may allow the team to implement the screens without a Spike.
In conclusion, use Spikes when they make sense to gain a deeper understanding of the upcoming PBIs. Don’t be afraid to take on the PBI without the Spike and use the Sprint Review as an opportunity for feedback.
