I am a QA/Test manager in my organization and until today I verified the quality of the software (tests written and executed and bugs fixed). Who will verify this in Scrum? How do I know that the team wrote and executed all the right tests? On the other hand I'm afraid that if I continue to do the verification the team will not feel empowered enough. But I need some verification process that "Done" is indeed "Done". What do you suggest?


6 Answers 6


One major idea in Scrum is that the team should agree on a "definition of done". Ideally, this is something like a set of objective criteria that anyone can verify by going through a checklist.

But to reduce the chance of something slipping through, it makes perfect sense to have a rule that verifying "done" most be performed by someone other than the person who implemented an item - or a designated QA guy like you (but that risks making you a bottleneck).

If in doubt, discuss is with the team and the Scrum Master and decide together.

  • +1 though the product owner is normally not considered part of the team - (s)he is usually drawn outside of the team's circle - yet does have (or should have) a say in the definition of done. It is the only way the product owner can (is allowed to) influence the way the team works. Feb 2, 2014 at 13:23
  • 1
    @MarjanVenema The Product Owner is very much considered a part of the Scrum Team. In fact, without the Product Owner, Scrum has little to no chance of being successful. Feb 3, 2014 at 10:18
  • 1
    @Derek: I think you're having a misunderstanding based on unclear terminology. There is both a "Scrum Team" and a "Development Team", with the latter being a part of the former, as well as the Product Owner and Scrum Master. Feb 3, 2014 at 10:30
  • 2
    @MichaelBorgwardt It's why I was so clear in my reply that the Product Owner is part of the Scrum Team. I agree that the Product Owner is not part of the Development Team but the context did not make it clear. I was hoping to clear confusion. Seems like I may have inadvertently created some :) Feb 3, 2014 at 11:10

I think there is an implicit assumption in the question. There is a difference between "accepted", when a Product Owner declares a backlog item or task has satisfied the Product Owner, and "done" meaning all work associated with the backlog item is complete.

However, there is regularly more to a task than that visible to the Product Owner, usually someone semi-technical at best, including (automated and manual) testing, documentation and review. The Product Owner is rarely in a position to know the technical aspects, let alone whether they are completed.

Therefore, it is ultimately up the team to determine what "done" means. The organization may have standards and different stakeholders will have their own requirements. The scrum master or relevant managers usually are responsible for collating and enforcing the list.

In your example, as the QA/Test manager, you are the one who says whether tests are complete. However, you may not be the best person to say whether the code has been reviewed, security requirements are met, the product is internationalized, documentation is complete or whatever else constitutes "done".


The only concept of "done" is whether or not a story as a whole is completed. The team should have created a definition of done that says when they feel a story is finished or not. This will typically include things such as "code has been reviewed", "nightly tests have been run", "all acceptance criteria have been met", etc. When these things have been accomplished, the team can feel confident they've done everything expected of them to finish a story.

During a sprint, if you're trying to determine if one of those items in the definition of done has been accomplished, just ask. Scrum and agile is all about open communication. If you are part of the team, ask your teammates if anyone has written the tests, or run them, or created the nightly job, etc. If you are a stakeholder, ask the scrum master.

If you sit outside the team but still must review the tests, have the team add "tests must be reviewed by user user3251930" as part of the definition of done. If that's what it takes for a story to be done, be honest about it and make it part of the process. The whole point of the "definition of done" is so that the team can know with certainty that they have done what is required to deliver quality software. If part of that is an external review, so be it.

Ultimately, it is the product owner who signs off on a particular story, so at the end of the day he or she has the final decision as to whether a story as a whole is done or not.

  • I need to review the tests, otherwise I wouldn't know if the correct tests were written. The definition of "Done" doesn't include the exact tests that should be written.
    – Eugene
    Feb 2, 2014 at 15:07
  • @user3251930: why do you need to review them? Do you not trust your team? Though, if you really do need to review them, make part of the definition of done be "tests have been reviewed by user3251930". Feb 2, 2014 at 15:14
  • If the customers get something that was not completely tested it would be really really bad. Maybe in time I'll be able to trust the team, I hope so.
    – Eugene
    Feb 2, 2014 at 15:20

First Question you should ask yourself

Are you the Scrum Master? if yes.

In scrum processes are controlled and managed by the Scrum Master.

How do you do it:

In the requirement phase you can use the user stories for each there is a test that needs to be verified.

In each Sprint The work items are pulled from the product backlog and directed by the product owner.each of them will have verification criteria as well.

Now in Scrum requirements dont change after the sprint has started .At the end of the Sprint you can analyze the verification according to the criteria for each item done.

If its done can only be found by the response of the Product owner.

Remember in Agile you "Embrace the change" even late into the development phase


The team decides. I use a checklist, for what's considered 'Done'. What's 'Done' per story, per sprint, per release.

As others have mentioned, ultimately the decision lies with the product owner.

  • is this only your personal opinion or you can back it up somehow?
    – gnat
    Feb 3, 2014 at 6:55

Agree that this is something the development/test team needs to define, depending on your own practices. Some projects run so agile that they're willing to risk releasing bugs to their alpha stream; some consider any bug which gets outside the development group a process failure.

The project I'm working on requires peer review of code changes, and requires that whoever wrote the code either provide/update regression tests or explain why it isn't possible to do so. (They and their reviewer(s) also have to certify that they've checked for known bad practices. We're generally Much Happier if they can show that they ran the full test suite and have gotten a clean result (or clean modulo known open issues, at least) The code then has to survive intensive automated unit and functional testing on multiple platforms to demonstrate that it doesn't cause any regressions against those, and it gets further checked for common antipatterns by an automated code analysis system. Only then do we accept it into the main development stream and mark the work item complete. Note that completing one work item may only be one step toward completing a larger-scale task or story.

That obviously doesn't guarantee that nobody finds a new way to fail, but it reduces the risk to an acceptable level without greatly impeding speed of development.

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.