Spike Solutions

I like James Shore's explanation of Spike Solutions. His focus seems to be on very short impromptu experiments (on the order of minutes). One thing about spikes that could use some more words are larger spikes. Sometimes I need to figure something out that may take more than a day. An example might be to experiment with one particular API for some new service I need to consume.

I recommend each team come to agreement on what's an acceptable maximum size for a spike. I recommend a day, or maybe two. If it will take more time than that, split it, just like you would for a story. Spikes need to have a clear acceptance criteria, a very specific question to answer. When the time-box is over, share the results with the team.

Often, such larger spikes are related to a user story and typically must be resolved before the story can be estimated. But for the spikes themselves, I recommend NOT estimating them. We want velocity to represent value added stories -- we want to measure the rate at which we add value. Either way, when using your velocity, when making release plans, you must understand your system and take into consideration when and how you come up with spikes and when you solve them. Do you find them late? Do you know about them but implement them late? If so, that represents unknown schedule risk.

I used to say that a consistent stream of day-sized spikes is good, but when I said that I would often forget to explain my context and assumptions. Having a continuous stream of new spikes that you solve almost as you create them makes sense if you are also doing continuous planning (without batching into large releases or without release commitments). Solving small spikes regularly keeps this activity from making velocity unstable.

Conversely, if you batch requirements into releases greater than, say, a couple months and if your organization is making release commitments, then in that case spikes represent risk in your backlog. Might want to knock out all spikes for the release right off the bat.

------------------

Wow, this is just my first post this year. I've been very busy with my LeadingAgile clients. It's time to get back to my writing!

Sprint "Commitments" are an Amortized Death March

Matt's tweet is provocative: Sprint "commitments" are an amortized death march.

If sprint commitments lead to a death march, something is wrong in your organization. Sprint commitments could be used by poor managers to browbeat the team.

Hey, you guys committed to this. I expect it to be done!

Not good.

The risk of a death march, however, is not the reason to not have a strong sprint commitment. You can (possibly) fix that problem. You can (possibly) have good, enlightened managers. Besides, there are many ways to use Scrum poorly. Should we throw out every misused practice?

No. But sprint commitments are dubious.

It's not the sprint commitment we are after. It's not what we really want in the end. It has no value on its own. What we're after is that thing we hope to get from having the sprint commitment. What we hope to get is a team that is committed to each other, working together to finish what they set out to do. We hope everyone works on what we agree to work on rather than whatever darn thing anyone wants to do. We hope to not have unfinished work at the end of the sprint.

Sprint commitments → no unfinished work at the end

Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.

A → B

In complex adaptive systems it doesn't always work out that way. I might even say it rarely works that way. Whether the sprint goes well or poorly, there are side effects of such policies. But this post isn't about the side effects. For the manager, though, when the sprint goes poorly the best possible outcome is...

Darn, this is harder than anticipated. But I committed to getting it done. Guess I'll put in some overtime.

If what is committed to is generally kept low (appropriate), pace should be sustainable over the long run even with some rare overtime. When appropriate overtime does happen:

That stunk! Not doing that again. Let's commit to less and plan better.

In this way, sprint commitment should drive careful planning.

But is careful planning in batch necessary or is it waste? It can be useful in some contexts, but bogus in others. What's the point of a sprint commitment if you are committing to something very small, knowing that you are going to add more work to the sprint? If we plan less work to meet a strong sprint commitment, and also plan to add more work to the sprint later, then we are approaching continuous planning and might as well make the jump to iteration-less flow (e.g. and use Kanban).

We want a stable velocity. We want teams to be predictable. But requiring a strong sprint commitment is neither necessary nor sufficient. It's other stuff that makes us predictable, namely: finishing sprints cleanly every time; good backlog grooming practices; good story estimation practices (if using Scrum); limiting WIP; not starting work you can't finish in time; the "keep it working" principle; refactoring and SOLID design principles; good release planning and intelligent use of spikes; and so forth.

Just work directly on that stuff.

Truthfully, I've used sprint commitments and have also gone without them. They are useful in certain context, and dangerous in others. I consider the leadership, the managers and scrum masters, the team's agile experience, and how much time I'll have to coach the team before making the call on sprint commitments.

Related Articles:

Matt Barcomb wrote a nice article on good and bad commitments. Go read that and the very thoughtful comments posted in reply.

I briefly touched on sprint commitments in my post on unstable velocity.