Experiment and Spike to Explore

We rarely know exactly how a feature will turn out. We have ideas, but until we’ve implemented the story, we don’t exactly know how it will work. That’s why we don’t do Big Design Up Front in agile. Instead, we think of the smallest possible experiment or prototype that we can learn from.

It’s easy to create waste without trying. Here are some ways I’ve seen teams create waste without meaning to do so:

• The team or an architect spent weeks defining an architecture up front and then the requirements changed.

• The team or members of the team said, “While I’m in there…” and implemented more of a feature set than the product owner needed now.

• The stories were so large the team spent considerable time in estimation.

• The stories were so large the team took a long time implementing anything. By then, the customers had left for another vendor.

I bet you’ve seen other examples of waste in projects.

Teams can avoid many of these problems if they experiment to try something, prototype something for feedback, and spike to see what this “story” will really take. Teams reduce waste as a side benefit of experiments, spikes, and prototypes.

What Are Spikes?
	Spikes are timeboxed prototypes that provide the team information about the rest of the feature or the feature set.

It’s even better when the team and the product owner write small stories. The smaller the story, the less work a team has in estimating the story or in writing the story or the necessary tests to support that story. The smaller the story, the faster the team can release it. And the smaller the story, the easier it is to experiment and understand if the customers want this feature or feature set.

Small stories allow a team to experiment with its ability to do everything. Keep your stories small.