I’ve been thinking a lot recently about the size of user stories in agile projects. The idea that I’ve been reflecting on is what if teams only worked with small, similarly-sized pieces of work, rather than exponentially larger blocks of work?
In theory, small user stories should be more predictable, should include less risk, less uncertainty and less complexity. They should, therefore, take less time to complete than larger user stories… you would think! Or as Mike Cohn put it in Agile Estimating and Planning (Prentice Hall, 2006), “small stories keep work flowing”.
One of my favourite books on agility is The People’s Scrum (Dymaxicon, 2013) by Tobias Mayer.
A lot of books on agility focus on the mechanics of how it all fits together, who needs to be where doing what with whom in order for the machine to work more effectively.
This book is different. It focuses not on the how, but challenges the why. It is open to critically questioning every aspect of agile with the intention of uncovering the core drivers behind agile practices.
Last Thursday evening, I gave a presentation entitled ‘Using business process modelling for creating a definition of ready and definition of done’ at the second Lean Agile Dundee meet-up at SolarWinds.
The second supporting agile/XP practice that I want to explore is ‘spike solutions’ or simply ‘spikes’.
What is a spike?
The name ‘spike’ comes from rock climbing. A piton (sometimes called a pin or peg) is a metal spike or wedge that is hammered into a crack in the rock to act as an anchor to secure the rope. This protects the climber from the consequences of a fall and to assist progress. The spike itself doesn’t move the climber closer to the top but it helps provide a safe path to do so.
Similarly, in software development, spikes help developers determine a safe path forward when knowledge is lacking about how to do something.
A software spike is a technical investigation—a small experiment to research the answer to a specific problem about how to do something.