A Common, but Bad, Idea
Please don’t do this:
It will hurt. Not right away, but around sprint 4 when the bugs found in sprint 3 for the stories built in sprint 2 need to be mixed in with the stories planned in sprint 3 for sprint 4. And then it’ll hurt more in sprint 5 and later when you have to start regression testing more and more code each sprint.
Instead, just do as much work as you can get really DONE in each sprint. Plan it, build it, test it, and deliver it. It’ll be hard to ensure that testing doesn’t get squeezed out the back of the sprint. It will. When that happens, try moving testing to the front of each story. Create your test cases as specifications and then do just enough development to make them pass. (Consider a tool like Cucumber for this, using it to drive Watir if you’re building a web app. Or look at Fit/Fitnesse if that’s more your style.)
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.
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.
@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.
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.
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!