Scrum - splitting test from a user story to next sprint

Question

I am wondering how to manage this sort of issue in the best, Agile way. Let's take our current situation as an example: we have two stories that are technically "complex" (simply put, big), that will take some time to be finished. QA testers wait for it to be done so they can test it. The stories are big with documentation and testing being subtasks of the story. During the first Sprint, the stories got put on the back burner because of urgent production bugs that needed to be fixed. We are soon ending our second sprint and yet again, these stories won't be resolved but now because documentation and testing will not have been completed.

So, can we split QA testing and documentation into separate stories rather than having them as subtasks so we can get stories like these resolved during a sprint?

For some background information:

• We have 3 week Sprints at the moment but everyone will transition to 2 week Sprints in Autumn so this sort of problem will be more prevalent. So we can't increase the length of our Sprints.
• If you wonder if we could split the stories smaller then no, it is already small considering. It is either done or not, implemented in our testing environment or not (we can't test a skateboard if it's still a board lying on the shelf).
• We do iterations, do a demo for our client and many more at the end of each Sprint and we do have a focus on delivering benefit to the user (functional, technical, etc) at each Sprint - but the release of our product isn't until next year. So we don't have the pressure of "delivering working software" as in releasing the whole thing at the end of each sprint. The product does work even though QA testing hasn't been done. So it wouldn't put the project as risk if we split testing and coding to two different Sprints.

So right now I have two stories with coding getting finished, but testing and documentation as subtasks that will stop the stories being resolved. I want to split the subtasks into stories so as to plan them into a Sprint when the coding is done. Is this okay or is there a better way to handle it?

Answer 1

No, splitting technical tasks off into new stories is not the answer. The idea behind delivering a "potentially releasable product increment" is that the stakeholders can say at the end of a sprint: "We like this. Let's put this in a beta test among selected customers." or even "Let's move the release date forward and beat our competition."
When they say that during a sprint review, you put yourself in a very weak position if you then have to tell your client that the product you so proudly showed isn't finished yet, because it isn't fully tested yet.

Also, if you get into the habit of making separate stories for documentation and testing, then you are telling the PO (and the client) that documentation and testing can be prioritized separately from the coding, which means that inevitably they will be moved further and further down the backlog, in favor of coding more and more features.

---

If you find that there are too many show-stopping interruptions that prevent you and your team from completing the regular work in a sprint, then you should first address why there are so many show-stoppers.

• Is the quality of the work you deliver really high enough? Should more effort be spent on preventing such serious issues to make it into production?
• Are all the reported issues really show-stoppers or could some of them actually have been postponed till the next sprint (only 3 weeks away worst case)? Has it been considered to abort the current sprint once a show-stopping bug comes in (all sprint-related work stops immediately and the entire team focuses exclusively on fixing the show-stopping issue)? If the stakeholders are not willing to abort a sprint to fix a show-stopper (and take the losses/delays that that implies), then the issue isn't really important enough to be called a show-stopper.

If you find that the stories are actually too big to be completed in one sprint, then you need to split them into slammer stories. Not by splitting off technical work, but by splitting off functionality, regardless of how hard that may be. Or you must accept that a story drags along for multiple sprints and you have to explain several times why not all planned stories were completed.

At a certain point, splitting stories becomes very hard because it is no longer obvious how a even smaller story can still deliver value to the stakeholders. If you get to that stage with a story that is still too large to confidently deliver in one sprint, then you need to get into a serious negotiation with the (relevant) stakeholders to discuss how to split the story further. You must not take no for an answer and you should be prepared to take steps that seem very radical, like supporting the feature only for a small sub-set of the users.
To take your skateboard analogy, even a skateboard that doesn't have wheels yet can be tested on some important points (like board length, width, strength, flexibility, etc.). It may not be as functional as you want it in a finished product, but it would be fine for an unreleased product increment and to give the stakeholders something they can use to get a feel for the final product they will be getting.

Answer 2

Stories should be the smallest possible unit of work that, by themselves, provide business value.

So that's the real question - does untested, undocumented code provide any value to your business?

Only the stakeholders of your Project within your business can really answer that.

Additionally... sure, non-automated testing needs to be done afterwards, but why couldn't you do documentation and automated testing during development? I don't see the need for a roadblock there.

Answer 3

No, you can not separate QA testing and documentation into separate stories. This will violate the philosophy of Scrum which requires simple, short, autonomous sprints. According to INVEST, the stories should be self-contained and Independent. Maybe this is a sign that your stories are not simple enough and you should re-examine how you write your stories.

You should find more creative ways to split the stories even further. Remove functionality, make them simpler. Add removed complexity andfunctionality in next sprints.

Answer 4

The answer you don't want to hear: Your stories are too big.

A story is 2-3 days of work for the team. Not 2-3 weeks.

You'll just have to regocnize the pattern, and provide ways to break it. It can be done. Always.

Team:

Get your team in the right frame of mind: I sometimes explain it to my team by drawing a square on a whiteboard: The complexity in a story is the square of the time. So a story that is 4 days instead of 2 days, has 4*4 = 16 units of complexity for bugs to hide in. A 2 day story only has 2*2 = 4 units for bugs to hide.
Smaller stories have fewer bugs, they're simpler and easier to find and fix.

Also: a 50% increase in effort, due to unforseen technical problems, is only a day on a small story. It's a week on your story-size. That's just not predictable anymore.

Testing is feedback. You want to keep the feedback-loop to your developers shorter, not longer.

Splitting:

If you think your stories can not be split; if you think you 'must' have everything before delivering: You are focussing on the product. Focus on the customer need instead. You are mixing the two until you think that 'customer need' is the same as 'a complete product'. Learn about storymapping.

As for your skateboard-analogy: Suppose my son is my customer, and he wants to ride that skateboard, and I have agreed to build him one.

If borrow one for him, I can fulfill his need, while I am working on the next increment of the product.

If I test the wheels, I can provide a product ('replacement wheels') for his old, broken skateboard, while I am working on the next increment of the product.

If I assemble the front wheels and test them, that reduces my risc. And as risc is negative value, I have reduced my negative value, and thus: risc reduction is value creation.

By focussing on his need ('riding a skateboard') instead of the product ('a skateboard), I can split a single skateboard in three valuable increments.