What to be included in acceptance criteria

Scrum doesn’t say anything about a “QA resource”, but it does describe a Product Owner who is responsible for the scope articulated on a Product Backlog. Scrum also says that the Development Team should help a Product Owner to refine the backlog, and that the PO - while remaining accountable - can have the team do some of the work involved in Product Backlog management.

Who is it then, who is asking *you* to formulate tests against PBIs? If you are the PO, it’s your backlog...and your prerogative to solicit the Development Team’s assistance in bringing items to a “ready” state.

Ian, agreed to everything you said but my question is what should be the scope of acceptance tests?

Do we need to add testing scenarios as acceptance tests  ?

It doesn’t sound as if they are needed from the Product Owner’s perspective. Do the Development Team need them to be able to estimate the work involved?

Yes it can help development team to estimate but do we need to cover maximum testing scenarios as acceptance tests?

If the Development Team say they actually need them, before Product Backlog items can be in a “ready” state for Sprint Planning, then the answer is yes. I’d be inclined to dig further into any such claim, however. Why would executable test scripts have to be in place, rather than (say) BDD-style acceptance criteria, just in order to estimate? Is that really what the Development Team are asking for, and if so, shouldn’t executable tests be written as part of the Sprint development effort? The barrier a team sets for work to be actionable ought to be kept as low as possible.

In the same light, at what point do you stop a Development Team requiring the code be written for a PBI in order for it to be ready?

Ian, lets say we need to write " BDD-style acceptance criteria " so what should be the scope for this?

Take example of a simple login page.

Please forgive me if I am off base but what is the difference between "Acceptance Criteria" and the "Definition of Done"? 

In the case of a simple login page, I expect the scope of the acceptance criteria would probably include the hiding of a password on entry, an action upon successful log in, and an action upon unsuccessful log in. Beyond that there may be additional specific scenarios around registration, authentication, accessibility and internationalization, response times, password renewal and perhaps even branding.

Acceptance criteria constitute a level of “done” and are generally applicable to Product Backlog items. The Definition of Done asserts the qualities of a releasable increment and comprises all levels of Done. For example if all connections must be HTTPS then this might be asserted at a general level in the Definition of Done.

Thanks a lot Ian, now its more clear. I was just confused if a PO is supposed to write acceptance tests so what should be the scope of those tests.