'Potentially Releasable Product' and splitting up testing

It's the end-of-sprint increment, rather than the individual stories, which must be potentially releasable. The Development Team are wholly accountable for the quality of the work they deliver...but that accountability only extends as far as their Definition of Done can take them.

A Definition of Done should not require developers to be subject matter experts, at least not in terms of understanding the product and the business. If the Product Owner wants to seek the advice of SME's before deciding if work is acceptable then it is his or her prerogative to do so. However, the PO would have to organize this in a timely fashion so incremental delivery is not put in delay.

To be clear: A no-go is to have user stories that are strictly 'dev' user stories that are to be tested at a later time.
In your described scenario, it is the Scrum Master's job to remove the impediment (bottleneck). Probably he would ask the team for ideas to solve this, and probably the solution will be getting developers to test.
In order to enable them, it is not necessary to make them SMEs. If they are not able to test it, how can they develop it? Obviously they do not know what the software is supposed to do. It is the PO's accountability to describe the PBIs clearly. If he is not able to do this, it is the Scrum Master's job to support him. The PO will probably have to talk to stakeholders. If the PO is not a SME himself, one possible option is to get a SME into the team, as the team should be cross-functional.

I am surprised to 'Dev' user stories. As scrum does not differentiate user stories as Dev or QA. User stories are the captured requirements in a specific format to ensure Actor, feature and result expected to be captured. As part of it even acceptance criteria/test is also captured. If it has not done in that way, probably PO needs more guidance and support from scrum master here. Also, what is agreed as 'Definition of Done' in your case? Each sprint need to deliver features/userstories which are fully 'Done' as per agreed 'Definition of Done' between PO and Development. And PO decides if feature is potentially releasable or not.

According to *our current definition of done, each user story, whether a "dev" or "qa" user story, is in a 'Done' state by the end of the sprint. For 'qa' user stories, the DOD is typically that all test cases have been passed and all bugs fixed and tested. For 'dev' user stories, that all development tasks within the user story are completed. Our Sprint DOD has been that all user stories are in a 'done' state by the end of the sprint, though it sounds like our practices need improvement.

What I understand at this point is that a user story should be one cohesive story describing a business objective. That user story contains all development and qa testing required to reach the business objective, and a 'done' state is typically that it's potentially ready for release at the end of the sprint. Let me know if I missed anything there...

Posted By golson on 18 Mar 2014 07:08 PM

What I understand at this point is that a user story should be one cohesive story describing a business objective. That user story contains all development and qa testing required to reach the business objective, and a 'done' state is typically that it's potentially ready for release at the end of the sprint. Let me know if I missed anything there...

You got it! Now you can improve. Define a definition of done for an increment, not for a sprint.
As you say, the content should include testing and bugfixing, because you need a potentially shippable increment.
This DoD helps you to decide, if a particular story is done. Basically, you can apply the definition for the increment to a story as well.

Best, Ludwig