Comments on: A Common, but Bad, Idea

By: Charles Bradley

Charles Bradley — Wed, 20 Apr 2011 10:40:35 +0000

And finally, if a spike is warranted, “design” may not in fact be the outcome. The only required outcome of the spike is that the large estimate uncertainty is removed. So, in some cases, the outcome could simply be a design route(not necessarily an actual design), or some other technical or business choice made.

What you describe above sounds like Spike Abuse and BDUF. In that, I agree — bad bad bad!

By: Charles Bradley

Charles Bradley — Wed, 20 Apr 2011 10:37:07 +0000

Agreed. Backlog Grooming in Sprint n-1 good, design in Sprint n-1 bad. Also, testing in Sprint n+1 bad.

The spike story issue you mention is a bad smell anyway. Spikes should only really occur for like 10% or less of stories. Further, design alone is not justification for a spike. Spikes only purpose is to remove *large estimate uncertainty*. For instance, if the team feels there are two feasible design routes, and the two different routes only vary by one story size (i.e. from Medium to Large or from 5 points to 8 points), then that is not large estimate uncertainty. Now, if the story size varies widely (say, from 3 points to 13 points, or Small to XXL), OR if the team just has no freaking clue how to estimate something, then a spike is warranted.

By: Richard Lawrence

Richard Lawrence — Wed, 20 Apr 2011 07:11:40 +0000

@Charles – Yes, of course Product Owners and teams should groom the backlog continuously. But they shouldn’t treat backlog grooming as the time to do detailed functional and technical design. For example, I’ve seen teams split almost every story to start with a spike that produced a design document. One sprint would produce the document. The next sprint would produce some code. Inevitably, the team would run out of time in that sprint because they took on too big a chunk of work, and testing would finish in the third sprint. This is what I’m recommending against, not a reasonable amount of ongoing backlog grooming.

Thanks for the comment.

By: Charles Bradley

Charles Bradley — Tue, 19 Apr 2011 12:58:25 +0000

I agree that testing should always be done in the same iteration as building. However, I disagree that planning the stories for the next iteration is a bad idea, or at least that doing some part of that planning is a bad idea. For instance, the Scrum Guide has been updated to say:
“…Scrum Teams often spend 10% of each Sprint grooming the product backlog to meet the
above definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit within one Sprint. They have been analyzed and thought through during the grooming process. When the Sprint Planning meeting occurs, these top priority Product Backlog items are well understood and easily selected…”

I think I realize what you were trying to say, but I just wanted to make this point.

By: DavidVTHokie

DavidVTHokie — Sun, 25 Oct 2009 23:46:00 +0000

Thanks Richard for the reminder. This at first feels like a safe fallback position for people who don’t want to go all-in with agile/scrum, but you’re exactly right about the “pain” coming in Sprint 4.