Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

'Potentially Releasable Product' and splitting up testing
Last Post 19 Mar 2014 01:44 AM by Ludwig Harsch. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Informative
Garrett Olson
New Member
New Member
Posts:5
Garrett Olson

--
16 Mar 2014 09:56 AM
    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 : )
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1614
    Ian Mitchell

    --
    16 Mar 2014 01:45 PM
    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.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    17 Mar 2014 12:33 AM
    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.
    Komal Kamat
    New Member
    New Member
    Posts:1
    Komal Kamat

    --
    17 Mar 2014 08:11 AM
    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.
    Garrett Olson
    New Member
    New Member
    Posts:5
    Garrett Olson

    --
    18 Mar 2014 02:08 PM
    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...
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    19 Mar 2014 01:44 AM

    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
    You are not authorized to post a reply.


    Feedback