Split story into a separate dev and qa stories in a sprint

  • 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?

  • 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.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2