One of the Scrum's ideas is to have a deliverable ready after the sprint's end. Development and testing should be completed on a story within the sprint, so that it could be released/deployed.

In this case, story is like a transaction in a relational database - it is either completed at the end of the sprint or is moved to the next one.

That's an approach we are utilizing on a project and there are some concerns about it. Some team members are reasoning that we should split big stories into a separate development and QA stories and track them separately. So that dev story could be picked up in one sprint and QA story could be scheduled to execute in the next one.

Potentially that might give more flexibility/control on each team member's load but might introduce some risks on release planning etc.

I wonder what are other pros/cons of having stories split into dev/QA? Does anyone had such transition performed in his team and what results has gotten?

  • Are your team members' concern based on assumptions or on past experience? If past experience, you might want to find out what caused the problems they try to avoid with such a splitting strategy. It might be overcommitment in which case a story split is ok (see my answer) but it might be unreliable availability of QA experts which needs to be tackled differently, either by ensuring better availability or by empowering more team members to perform QA tasks. Feb 27 '20 at 12:27
  • 1
    This issue is somewhat inherent in Scrum. Some stories will take more than a 2-week sprint before you can deliver an increment that has business value. There are many ways of dealing with this - but separate stories for Dev and QA is not one of them. For proof - how do you deal with a QA fail if the Dev is considered done? Clearly the Dev isn't done until the QA is complete.
    – Baracus
    Feb 27 '20 at 12:58
  • 3
    I'm not an initiate of the scrum religion, but I thought that part of the point was to focus on customer value? The customer gets no value from a dev sprint, only from a QA sprint. And if QA reject a sprint and sends it back for rework, nobody gets any value. I thought part of the covert goal of scrum was to create self organizing teams focused on customer value - this arrangement creates two implicitly competing teams and imposes a serious impediment to self-organizing. Were I involved, I would push for one team, one effort, one customer incremental value.
    – MCW
    Feb 27 '20 at 13:00
  • Isn't this a duplicate of pm.stackexchange.com/questions/21871/…?
    – sonstabo
    Feb 27 '20 at 13:48

To quote from the Scrum Guide

An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

You will encounter various issues splitting stories as you describe:

  1. The main problem is that the "dev stories" won't form part of a releasable increment. They are only actually releasable once the corresponding "QA stories" are complete.
  2. Related, you should have a sprint goal for each sprint and select stories which will deliver it if completed within the sprint. This will be extremely tricky if you have a mix of new dev stories and then QA stories related to your previous sprint.
  3. Even though your team may declare a "dev story" complete, there is a strong chance it will require rework off the back of the QA story and so isn't actually done. This will cause problems in a variety of areas, for example it will give you inaccurate metrics for how long a story really takes to be "done done".
  4. Scrum is based on the whole development team being accountable for delivering stories as a single unit. Introducing a Dev/QA split goes against this.

A much better approach would be to look into ways to split stories into smaller ones that are capable of being fully developed and tested within a single Sprint.

I would suggest:

  1. Read about INVEST, an acronym covering various concepts which make up a good user story.
  2. Learn about techniques for splitting complex user stories into simpler ones which each still deliver value. SPIDR is a useful acronym for possible ways to split stories and is worth looking up.
  3. Make sure you have a Definition of Done which is understood across your team and makes clear what is necessary for a piece of work to be complete.
  • Thanks for acronyms, they might help with breaking stories into smaller ones.
    – Mykola
    Feb 28 '20 at 15:22

Even if you split a story into DEV and QA parts, it remains one story in reality. So at the end of a sprint in which you completed the DEV part you made no measurable progress since this story isn't done, and only done stories count towards the sprint results. You're carrying unfinished work over into the next sprint which creates planning uncertainty and risk.

If stories are too big to be finished in one sprint, you should split them, but into substories that each can be implemented completely within one sprint and yield potentially releasable results (in my opinion even if the first part does not provide much direct value to the customer.)

  • Thanks for idea of "measurable progress". Spltting a story would make not so obvious what to measure.
    – Mykola
    Feb 28 '20 at 15:17

Ruaidhri's answer covered most of the points, I would like to just add a couple more.

The primary focus in Scrum should be to deliver value to the customer, frequently.

  • If you split the user stories then you turn them into 'not user stories'. Would your story for QA be like "As a user, I would like the registration form to work as correctly"?
  • You will not be delivering any value in a sprint most of the time: A functionality with bugs is not valuable to the end-user as it cannot be used as intended.

If you plan for DEV US(User Stories) in Sprint 1 and QA US in Sprint 2, when do you plan to work on the defects identified in coding during sprint 1? And what if the input from Sprint 1 development is to be used in sprint 2? You are introducing rework that would keep increasing for successive sprints.

  • It will reduce the scope of improvement for the team: Instead of splitting the stories team should experiment with practices like Test-Driven Development.

Let's look at a few scenarios:

The developers finish coding a story in a sprint. Progress is reported as good. The next sprint tests reveal that the new code corrupts the database. Not only does the change need to fixed, but also the database on several environments now needs to be cleaned up. The progress that was reported as good is now the opposite.

The developers finish coding a story in a sprint. Progress is reported as good. The next sprint a bug is found and a developer is asked to fix it. The developer is worried that if they spend time fixing the bug the developers won't complete the work they planned in the sprint.

The developers finish coding a story in a sprint. Progress is reported as good. The next sprint a tester takes a look at the story and realises that the coding approach taken makes it hard to test. They are really disappointed as a slightly different approach would have saved them a lot of testing time.

The developers finish coding a story in a sprint. Progress is reported as good. The next sprint a bug is found in the story, but the developer who was working on it is now on holiday. Somebody else has to pick up the fix and it takes them quite a while to complete.


We introduced "power of three" concept in our team to cover this, influenced by Atlassian. First - there are no QA defined in Scrum. Its Product Owner, Scrum Master and Team Member. As others have mentioned, the team is cross-functional and self-organizing. You might have team-members that are 100% testers, but they are not QA's by definition. That said, I'll use a dev/qa/functional description in my example below.

Power of three means that QA goes from being the traditional 'Quality Assurance' to 'Quality Assistance'. Once a new development task (US, PBI, whatever) is about to get started on, the dev, qa and functional (product owner or liaison) sit down and discuss what the task is all about:

  • what is the UI like (if applicable)
  • what are the business rules
  • how should exceptions be managed, etc.

This is done to make sure that all parties have the same understanding of what is about to be created to reduce rework later on.

Then the QA, now in 'assistance' mode, discuss with the developer how this should be tested and verified by the developer him/herself - what they should focus on, negative test-cases that should be remembered, edge-cases, etc. This provides the developer with input on testing the adjustment - the responsibility is still with the dev.

The QA in the more 'traditional' role will then focus on different kinds of regression testing, maybe plan to add some additional regression testing because they know that the last time this area was touched, 'something unforeseen happened'.

This should lead to a DoD on the task once the developer is done and have the responsibility correctly placed.

Your Answer

