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?


4 Answers 4


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.

  • To add, we are five teams who work on similar product and we all pitch in with our expertise and time if something critical happens. Whether it is in production or another department. But I agree, we should always ask if it can wait but unfortunately during these two sprints it couldnt. Also the team has full control over their own backlogg. But I understand better why it is bad to split. The developer argued that the two stories (implementing new service for fetch and update) was so similar that it should be done parallell to maximize the work - should I have stopped him instead?
    – hoxinabox
    Commented Jun 22, 2017 at 11:03
  • @hoxinabox: It probably would have given you a better chance of completing one of those stories if they were performed sequentially or by different developers. This call can be really hard to make when the stories come up the first time, but I think the developer should have been told to focus on one story first once they had rolled over to the next sprint. Commented Jun 22, 2017 at 16:37

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.

  • You're right in your comment. The stories right now are implementing new services. Since we have large code base, the team is sometimes unsure where the code is implemented and where it should be tested since these decisions sometimes come during development (in the story). So that affects automated testing, plus not being sure at what the end service will return. So it is easier for the team to do other work while waiting for the code to get at least 90% finished.
    – hoxinabox
    Commented Jun 22, 2017 at 10:58
  • "why couldn't you do documentation and automated testing during development?" Could be a matter of resource availability... Commented Jun 24, 2017 at 4:25

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.


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.


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.


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.

  • Thanks for the comment! We have done story mapping starting this project and we try having users needs in mind even in technical stories (as in why are we doing this). The two stories right now are implementing two new services for retrieving and updating information (not sure how to split a service that is or isn't there) The developer found the work to be so similar, that it should and could be done parallell so to maximize effectiveness. Should I have instead recommended him to only focus on one and left the other for another time?
    – hoxinabox
    Commented Jun 22, 2017 at 10:54
  • @hoxinabox If work is "so similar", it shouldn't be "duplicate work" but rather work on a generalised part and two instantiations. This could mean that you're creating an additional PBI. -- Your User Stories seem to be Epics. Epics are supposed to be broken down into smaller User Stories. And keep in mind that the PBIs do not have to be User Stories. If you have to implement sophisticated stuff under the hood, then you can derive a requirement / architecture / design detail from the User Story,have it agreed, and present e.g. the performance of such an artefact at the end of the Sprint. Commented Jun 24, 2017 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.