5

The problem I came across:

  • A 2-week Sprint is close to the end (let's say 80% of the time has passed by)
  • A particular user story has just been completed (and has unit tests)

What next? Testing takes time, especially if a special environment should be deployed. So at the end of the Sprint I usually have several user stories under QA, so should I mark them as completed, or not? (Possibly, the question could be rephrased as: 'Should the "QA COMPLETED" condition be included into the Definition Of Done?')

  • Hi JJ, welcome to PMSE! I believe would be nice if you could mention what's your / your company concept of QA on your question, as a major part of the answers will depend on it. – Tiago Cardoso Jan 24 at 8:40
  • QA staff is a part of scrum team, we have CI and as soon as user story "finished" and unit tested it goes to build and via CI goes test stage, perform automated integration tests and QA staff start to test manually ( that parts of system which testing are not automated) – J.J. Beam Jan 24 at 9:28
8

The direct answer for almost all teams is that QA must be complete to call a user story done. I would take that further and say that I have never worked with a team where this was not true.

The More Thorough Answer

In Scrum, a product increment (the product as it stands at the end of the sprint) must be "potentially shippable". This is a confusing term, but what it means is this:

The decision to ship a product to end users or not should be a business decision (do the available features provide a significant enough value to the end users that it is worth the cost to give it to them and the stress of them adopting the new version of the software). If there are technical reasons why the product can't be shipped (bugs, not QA'd, not in a deployable state, etc), then it is no longer a business decision. Therefor, a product increment is considered potentially shippable if there are no technical reasons that the product cannot be shipped to end users.

The "Definition of Done" acts as a list of those items that must be completed in order to meet the criteria for a Potentially Shippable product. So, the more complete answer to your question would be: If QA tests must run and pass before your product can be shipped to end users, then it should be in your definition of done and must be completed in the sprint in order to move those backlog items to a "Done" state.

  • Thank you! And how to treat user stories which are under QA at the end of the sprint? They are almost done. Suppose the user story has 5 story points ( difficult). So need it to be reestimate for the next sprint? And current sprint should be accepted as failed? – J.J. Beam Jan 17 at 13:23
  • 2
    I would say you rarely reestimate a story after it has been started (some would say never). You just carry it over and all of the points go into the sprint where it is complete. This won't matter in the average velocity (the averaging will even it out) but you will see it in the volitility of sprint-to-sprint velocity, especially if it happens often and this is a great trend to look at in the retrospective. For the current sprint, you failed to meet your goal. If the culture in the company is that the team will be unfairly treated for this, I'd find a euphamism for "failed". – Daniel Jan 17 at 17:43
3

A story is not "done" till it meets its functionality and is tested for completely.That means you need to bring in QA within your sprint and not as a separate stage. That includes functional in-sprint testing as well as system and regression testing . This is not possible until the team adopts engineering practices such as CI/CD , automation testing .I assure you it is not an immediate state , but definitely attainable given the infrastructure and effort.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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