Skip to main content

'Potentially Releasable Product' and splitting up testing

Last post 06:44 am March 19, 2014 by Ludwig Harsch
5 replies
02:56 pm March 16, 2014

The Scrum team I'm on had three developers and one QA test engineer (me). The bottleneck for our sprints has been QA testing -- to get around this bottleneck and still utilize our developers' time, we'll often have user stories that are strictly 'dev' user stories that are to be tested at a later time. My understanding is a user story should be 'potentially releasable' at the end of each sprint, and in the case just described, it would *not be 'potentially releasable' as the testing has not been completed. Getting developers to test is a no-go as they're not trained subject matter experts in the use of the software.

Am I correctly understanding the definition of 'potentially releasable'? Any insight is appreciated : )


06:45 pm March 16, 2014

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.


05:33 am March 17, 2014

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.


01:11 pm March 17, 2014

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.


07:08 pm March 18, 2014

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


06:44 am March 19, 2014


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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.