Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Article on Story Testing

Expand Messages
  • Peter Stevens (cal)
    Hi Charles, Thanks for this! One of my favorites test forms is How to Demo -- a simple workflow which can be used to demonstrate that the function works as
    Message 1 of 9 , Apr 11, 2011
    • 0 Attachment
      Hi Charles,

      Thanks for this!

      One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

      Cheers,

      Peter



      On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
       
      Hi folks,

      I've written a new article on User Story Testing, thought you might be interested.

      Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

      • Style 1: Bullet Points
      • Style 2: “Test with…”
      • Style 3: “Test that…”
      • Style 4: Given/When/Then
      • Style 5: Specification By Example – Conceptual Form
      • The Best Style: Mix and Match!

      Full article here:

      http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      -- 
      Peter Stevens, Partner 
      DasScrumTeam AG 
      
      direct: +41 44 586 6450 
      cell:   +41 79 422 6722
      skype:  peterstev
      
      blog:   http://scrum-breakfast.com
      
    • Charles Bradley - Scrum Coach CSM PSM I
      Peter, interesting idea. Are you using this How to Demo style to essentially ask the Product Owner, Ok, so you told us kind of what you wanted. How will we
      Message 2 of 9 , Apr 11, 2011
      • 0 Attachment
        Peter, interesting idea.

        Are you using this "How to Demo" style to essentially ask the Product Owner, "Ok, so you told us kind of what you wanted.  How will we demo this to the stakeholders at the end of the sprint?"

        If so, what method have you had success with, in terms of recording/remembering the answer to that question?  Or is it necessary to record anything?

         
        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/



        From: Peter Stevens (cal) <peterstev@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Mon, April 11, 2011 3:54:15 AM
        Subject: Re: [scrumdevelopment] Article on Story Testing



        Hi Charles,

        Thanks for this!

        One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

        Cheers,

        Peter



        On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
         
        Hi folks,

        I've written a new article on User Story Testing, thought you might be interested.

        Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

        • Style 1: Bullet Points
        • Style 2: “Test with…”
        • Style 3: “Test that…”
        • Style 4: Given/When/Then
        • Style 5: Specification By Example – Conceptual Form
        • The Best Style: Mix and Match!

        Full article here:

        http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


         
        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/



        -- 
        Peter Stevens, Partner
        DasScrumTeam AG

        direct: +41 44 586 6450
        cell: +41 79 422 6722
        skype: peterstev

        blog: http://scrum-breakfast.com


      • Peter Stevens (calendar)
        Hi Charles, With the how-to-demo, I am trying to help team and product owner achieve a common understanding of what the backlog item means and what is expected
        Message 3 of 9 , Apr 11, 2011
        • 0 Attachment
          Hi Charles,

          With the how-to-demo, I am trying to help team and product owner achieve a common understanding of what the backlog item means and what is expected of the implementation.

          I like to see the PBI expressed as a proper user story, but a complete sentence is usually enough (particularly when the stories are at the 'grain of sand' level for implementation). The PBI's title is complemented by the how-to-demo workflow. (If you will, these two elements are the Card and Confirmation of Ron's 3 C's). I have found the title of the PBI and the how-to-demo workflow usually delimit the scope of the story fairly well. The workflow may also suggest points for slicing the story into smaller stories if it appears too big for the sprint.

          I encourage teams to ask the PO 'how do we demo this to you' during the sprint planning.  So yes, the team should record it in a suitable place (back of the card, comments in the Target Process story, the story's Wiki page, whatever).  The team can refer to the workflow during implementation (both for achieving a good implementation and pushing back on scope creep). Having the workflow succeed becomes part of the definition of done. At the sprint review, the team walks through the same work-flow and hopefully everyone is happy!

          Cheers,

          Peter


          On 4/11/11 5:52 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
           
          Peter, interesting idea.

          Are you using this "How to Demo" style to essentially ask the Product Owner, "Ok, so you told us kind of what you wanted.  How will we demo this to the stakeholders at the end of the sprint?"

          If so, what method have you had success with, in terms of recording/remembering the answer to that question?  Or is it necessary to record anything?

           
          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/



          From: Peter Stevens (cal) <peterstev@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Mon, April 11, 2011 3:54:15 AM
          Subject: Re: [scrumdevelopment] Article on Story Testing



          Hi Charles,

          Thanks for this!

          One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

          Cheers,

          Peter



          On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
           
          Hi folks,

          I've written a new article on User Story Testing, thought you might be interested.

          Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

          • Style 1: Bullet Points
          • Style 2: “Test with…”
          • Style 3: “Test that…”
          • Style 4: Given/When/Then
          • Style 5: Specification By Example – Conceptual Form
          • The Best Style: Mix and Match!

          Full article here:

          http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


           
          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/



          -- 
          Peter Stevens, Partner 
          DasScrumTeam AG 
          
          direct: +41 44 586 6450 
          cell:   +41 79 422 6722
          skype:  peterstev
          
          blog:   http://scrum-breakfast.com
          



        • Charles Bradley - Scrum Coach CSM PSM I
          Peter, I like your concept. I have an advanced story testing style that uses something akin to a flowchart to help express tests that ensure a certain app
          Message 4 of 9 , Apr 11, 2011
          • 0 Attachment
            Peter,

            I like your concept.  I have an "advanced" story testing style that uses something akin to a flowchart to help express tests that ensure a certain app workflow. 

            However, what you're describing is somewhat different.  It sounds like you're using the "How to Demo" method as a way of creating confirmations/tests.  This "demo workfklow" somewhat reminds me of the User/System interactions that are described by Sea Level Use Cases.  The only downside about specifying workflow/pageflow up front like that is that it gets more into the "how" than requirements should get.  OTOH, workflow has to be designed sometime, and UI interactions should be done in collaboration with the PO anyway, so I guess it's an ok way of doing it.

            I also see your "How will we demo?" question as a very strong cousin to the techniques described in "Agile Testing."  Their technique, IIRC, is something like "How will I know this new feature is in the system?".  I think I've also heard "Agile" Bob Hartman phrase it as "What will the feature look like in the system when I'm done?".  Bob said something like, "there are only two questions to ask the customer.  'What do you want?' AND 'What will it look like in the system when I'm done?' "

            I'm not trying to say your idea is not original, because I think it is.  I'm just saying it reminds me of other similar ideas.

            Ponder on this, I will.
             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



            From: Peter Stevens (calendar) <peterstev@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Mon, April 11, 2011 12:31:30 PM
            Subject: Re: [scrumdevelopment] Article on Story Testing



            Hi Charles,

            With the how-to-demo, I am trying to help team and product owner achieve a common understanding of what the backlog item means and what is expected of the implementation.

            I like to see the PBI expressed as a proper user story, but a complete sentence is usually enough (particularly when the stories are at the 'grain of sand' level for implementation). The PBI's title is complemented by the how-to-demo workflow. (If you will, these two elements are the Card and Confirmation of Ron's 3 C's). I have found the title of the PBI and the how-to-demo workflow usually delimit the scope of the story fairly well. The workflow may also suggest points for slicing the story into smaller stories if it appears too big for the sprint.

            I encourage teams to ask the PO 'how do we demo this to you' during the sprint planning.  So yes, the team should record it in a suitable place (back of the card, comments in the Target Process story, the story's Wiki page, whatever).  The team can refer to the workflow during implementation (both for achieving a good implementation and pushing back on scope creep). Having the workflow succeed becomes part of the definition of done. At the sprint review, the team walks through the same work-flow and hopefully everyone is happy!

            Cheers,

            Peter


            On 4/11/11 5:52 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
             
            Peter, interesting idea.

            Are you using this "How to Demo" style to essentially ask the Product Owner, "Ok, so you told us kind of what you wanted.  How will we demo this to the stakeholders at the end of the sprint?"

            If so, what method have you had success with, in terms of recording/remembering the answer to that question?  Or is it necessary to record anything?

             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



            From: Peter Stevens (cal) <peterstev@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Mon, April 11, 2011 3:54:15 AM
            Subject: Re: [scrumdevelopment] Article on Story Testing



            Hi Charles,

            Thanks for this!

            One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

            Cheers,

            Peter



            On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
             
            Hi folks,

            I've written a new article on User Story Testing, thought you might be interested.

            Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

            • Style 1: Bullet Points
            • Style 2: “Test with…”
            • Style 3: “Test that…”
            • Style 4: Given/When/Then
            • Style 5: Specification By Example – Conceptual Form
            • The Best Style: Mix and Match!

            Full article here:

            http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


             
            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/



            -- 
            Peter Stevens, Partner
            DasScrumTeam AG

            direct: +41 44 586 6450
            cell: +41 79 422 6722
            skype: peterstev

            blog: http://scrum-breakfast.com





          • Charles Bradley - Scrum Coach CSM PSM I
            ... Peter, One other small side note. I hope that when you say how do we demo this to you? , you re referring to some sort of PBI signoff/acceptance activity
            Message 5 of 9 , Apr 11, 2011
            • 0 Attachment
              > ask the PO 'how do we demo this to you' during
              the sprint planning.

              Peter,

              One other small side note.  I hope that when you say "how do we demo this to you?", you're referring to some sort of PBI signoff/acceptance activity that occurs *before* the Sprint Review.  I know many teams, mistakenly demo to the PO as a form of acceptance at the Sprint Review.  If you read the Scrum Guide closely, the Sprint Review is not an attempt to get signoff/approval from the PO or from the stakeholders.  As such, the "demo" to the PO should happen as soon as the dev team thinks the PBI is complete, and said demo should be to the PO and PO only, during the Sprint.  The demo at the Sprint Review is to help the PO lead a discussion with the stakeholders about what backlog items are to be attempted next.  I see many teams who put the dev team on one side of the convo and the PO + stakeholders on the other side of the convo.  I strongly believe that is a mistake. 

              Summary:
              • PBI's are accepted/signed off on by the PO, prior to the Sprint Review. 
                • The best practice, IMO, is to have PBI's accepted by the PO as soon as the dev team thinks they are complete.
              • The Sprint Review is not a signoff meeting.  It is not for the PO to accept/signoff on PBI's, and it is not for stakeholders to signoff on PBI's.
                • Stakeholders don't sign off on PBI's anyway -- they just give feedback that helps create new PBI's.
              • Feedback about the just finished work and demo, from stakeholders and The Scrum Team, is encouraged.
              • The Sprint Review's demo is solely for the purpose of collaborating on what is to be attempted next. 
              • If the stakeholders want changes to the just finished functionality, that is fine.  Those are new PBI's.
              • There are other aspects to the Sprint Review, but these are the ones related to this "who to demo to" topic.

               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/



              From: Peter Stevens (calendar) <peterstev@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Mon, April 11, 2011 12:31:30 PM
              Subject: Re: [scrumdevelopment] Article on Story Testing



              Hi Charles,

              With the how-to-demo, I am trying to help team and product owner achieve a common understanding of what the backlog item means and what is expected of the implementation.

              I like to see the PBI expressed as a proper user story, but a complete sentence is usually enough (particularly when the stories are at the 'grain of sand' level for implementation). The PBI's title is complemented by the how-to-demo workflow. (If you will, these two elements are the Card and Confirmation of Ron's 3 C's). I have found the title of the PBI and the how-to-demo workflow usually delimit the scope of the story fairly well. The workflow may also suggest points for slicing the story into smaller stories if it appears too big for the sprint.

              I encourage teams to ask the PO 'how do we demo this to you' during the sprint planning.  So yes, the team should record it in a suitable place (back of the card, comments in the Target Process story, the story's Wiki page, whatever).  The team can refer to the workflow during implementation (both for achieving a good implementation and pushing back on scope creep). Having the workflow succeed becomes part of the definition of done. At the sprint review, the team walks through the same work-flow and hopefully everyone is happy!

              Cheers,

              Peter


              On 4/11/11 5:52 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
               
              Peter, interesting idea.

              Are you using this "How to Demo" style to essentially ask the Product Owner, "Ok, so you told us kind of what you wanted.  How will we demo this to the stakeholders at the end of the sprint?"

              If so, what method have you had success with, in terms of recording/remembering the answer to that question?  Or is it necessary to record anything?

               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/



              From: Peter Stevens (cal) <peterstev@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Mon, April 11, 2011 3:54:15 AM
              Subject: Re: [scrumdevelopment] Article on Story Testing



              Hi Charles,

              Thanks for this!

              One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

              Cheers,

              Peter



              On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
               
              Hi folks,

              I've written a new article on User Story Testing, thought you might be interested.

              Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

              • Style 1: Bullet Points
              • Style 2: “Test with…”
              • Style 3: “Test that…”
              • Style 4: Given/When/Then
              • Style 5: Specification By Example – Conceptual Form
              • The Best Style: Mix and Match!

              Full article here:

              http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


               
              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/



              -- 
              Peter Stevens, Partner
              DasScrumTeam AG

              direct: +41 44 586 6450
              cell: +41 79 422 6722
              skype: peterstev

              blog: http://scrum-breakfast.com





            • Ron Jeffries
              Hello, Charles. On Monday, April 11, 2011, at 5:26:09 PM, you ... Yes. Using the demo as an acceptance test means that the team does not know what s done
              Message 6 of 9 , Apr 11, 2011
              • 0 Attachment
                Hello, Charles. On Monday, April 11, 2011, at 5:26:09 PM, you
                wrote:

                > One other small side note. I hope that when you say "how do we demo this to
                > you?", you're referring to some sort of PBI signoff/acceptance activity that
                > occurs *before* the Sprint Review. I know many teams, mistakenly demo to the PO
                > as a form of acceptance at the Sprint Review. If you read the Scrum Guide
                > closely, the Sprint Review is not an attempt to get signoff/approval from the PO
                > or from the stakeholders. As such, the "demo" to the PO should happen as soon
                > as the dev team thinks the PBI is complete, and said demo should be to the PO
                > and PO only, during the Sprint. The demo at the Sprint Review is to help the PO
                > lead a discussion with the stakeholders about what backlog items are to be
                > attempted next. I see many teams who put the dev team on one side of the convo
                > and the PO + stakeholders on the other side of the convo. I strongly believe
                > that is a mistake.

                Yes. Using the demo as an acceptance test means that the team does
                not know what's done until it is too late.

                Ron Jeffries
                www.XProgramming.com
                Ron Jeffries, speaking for Boskone ... Out.
              • Peter Stevens (cal)
                Hi Charles, Thanks, the how-to-demo concept is somewhere on the border between conversation and confirmation. The concept grew out of the following situation:
                Message 7 of 9 , Apr 12, 2011
                • 0 Attachment
                  Hi Charles,

                  Thanks, the how-to-demo concept is somewhere on the border between conversation and confirmation. The concept grew out of the following situation:

                  A developer was explaining his problems with scope creep: "When I look at the title of this story, the development is done. When I look at the acceptance criteria we have defined, the story is done too. But there was this reference to satisfying the requirements of chapter 4.1.3 in the spec, which no one had really looked at, and that is a can or worms!" Because of the complexity discovered en route, the stories weren't getting done.

                  BTW - the spec was a hold over from how they worked previously. The product generated digital maps from aerial photos and GPS data. This process requires math bordering on magic, so the actual acceptance tests were so esoteric that only a few people on the development team really understood them.

                  Our solution was to consider the story's title and its how-to-demo as defining the borders of the story. These two items determine the scope of the story. The spec was deprecated - a useful guide for the details, but not determining for the scope of any individual story. So discovering new things in the spec resulted in new product backlog items, not growth in committed stories.

                  Creating the how-to-demo is part of grooming the product backlog, so it can be created either at the estimation/release planning meeting or in sprint planning 1, or somewhere along the way. It's part of the Conversation, so it shouldn't happen too far in advance.

                  Cheers,

                  Peter


                  On 11.04.11 23:00, Charles Bradley - Scrum Coach CSM PSM I wrote:
                   
                  Peter,

                  I like your concept.  I have an "advanced" story testing style that uses something akin to a flowchart to help express tests that ensure a certain app workflow. 

                  However, what you're describing is somewhat different.  It sounds like you're using the "How to Demo" method as a way of creating confirmations/tests.  This "demo workfklow" somewhat reminds me of the User/System interactions that are described by Sea Level Use Cases.  The only downside about specifying workflow/pageflow up front like that is that it gets more into the "how" than requirements should get.  OTOH, workflow has to be designed sometime, and UI interactions should be done in collaboration with the PO anyway, so I guess it's an ok way of doing it.

                  I also see your "How will we demo?" question as a very strong cousin to the techniques described in "Agile Testing."  Their technique, IIRC, is something like "How will I know this new feature is in the system?".  I think I've also heard "Agile" Bob Hartman phrase it as "What will the feature look like in the system when I'm done?".  Bob said something like, "there are only two questions to ask the customer.  'What do you want?' AND 'What will it look like in the system when I'm done?' "

                  I'm not trying to say your idea is not original, because I think it is.  I'm just saying it reminds me of other similar ideas.

                  Ponder on this, I will.
                   
                  -------
                  Charles Bradley, CSM, PSM I
                  Experienced Scrum Coach
                  My blog: http://scrumcrazy.wordpress.com/



                  From: Peter Stevens (calendar) <peterstev@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Mon, April 11, 2011 12:31:30 PM
                  Subject: Re: [scrumdevelopment] Article on Story Testing



                  Hi Charles,

                  With the how-to-demo, I am trying to help team and product owner achieve a common understanding of what the backlog item means and what is expected of the implementation.

                  I like to see the PBI expressed as a proper user story, but a complete sentence is usually enough (particularly when the stories are at the 'grain of sand' level for implementation). The PBI's title is complemented by the how-to-demo workflow. (If you will, these two elements are the Card and Confirmation of Ron's 3 C's). I have found the title of the PBI and the how-to-demo workflow usually delimit the scope of the story fairly well. The workflow may also suggest points for slicing the story into smaller stories if it appears too big for the sprint.

                  I encourage teams to ask the PO 'how do we demo this to you' during the sprint planning.  So yes, the team should record it in a suitable place (back of the card, comments in the Target Process story, the story's Wiki page, whatever).  The team can refer to the workflow during implementation (both for achieving a good implementation and pushing back on scope creep). Having the workflow succeed becomes part of the definition of done. At the sprint review, the team walks through the same work-flow and hopefully everyone is happy!

                  Cheers,

                  Peter


                  On 4/11/11 5:52 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
                   
                  Peter, interesting idea.

                  Are you using this "How to Demo" style to essentially ask the Product Owner, "Ok, so you told us kind of what you wanted.  How will we demo this to the stakeholders at the end of the sprint?"

                  If so, what method have you had success with, in terms of recording/remembering the answer to that question?  Or is it necessary to record anything?

                   
                  -------
                  Charles Bradley, CSM, PSM I
                  Experienced Scrum Coach
                  My blog: http://scrumcrazy.wordpress.com/



                  From: Peter Stevens (cal) <peterstev@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Mon, April 11, 2011 3:54:15 AM
                  Subject: Re: [scrumdevelopment] Article on Story Testing



                  Hi Charles,

                  Thanks for this!

                  One of my favorites test forms is 'How to Demo' -- a simple workflow which can be used to demonstrate that the function works as desired. Although not as detailed as other methods, it particularly useful when negotiating the scope of the story between Product Owner and Team. It encourages both parties to define stories which are valuable to the customer or user. It is also helpful in preventing Scope Creep during the sprint.

                  Cheers,

                  Peter



                  On 10.04.11 16:33, Charles Bradley - Scrum Coach CSM PSM I wrote:
                   
                  Hi folks,

                  I've written a new article on User Story Testing, thought you might be interested.

                  Summary: In order for a team to get really good at User Stories, they need to learn to be able to efficiently express their story tests. Story tests are also known as “User Story Acceptance Tests”, “Acceptance Tests”, “Confirmations”, and “Test Confirmations.” In this article, I list the most basic styles for expressing Story Tests:

                  • Style 1: Bullet Points
                  • Style 2: “Test with…”
                  • Style 3: “Test that…”
                  • Style 4: Given/When/Then
                  • Style 5: Specification By Example – Conceptual Form
                  • The Best Style: Mix and Match!

                  Full article here:

                  http://scrumcrazy.wikispaces.com/Basic+Story+Testing+Styles


                   
                  -------
                  Charles Bradley, CSM, PSM I
                  Experienced Scrum Coach
                  My blog: http://scrumcrazy.wordpress.com/



                  -- 
                  Peter Stevens, Partner 
                  DasScrumTeam AG 
                  
                  direct: +41 44 586 6450 
                  cell:   +41 79 422 6722
                  skype:  peterstev
                  
                  blog:   http://scrum-breakfast.com
                  







                  -- 
                  Peter Stevens, Partner 
                  DasScrumTeam AG 
                  
                  direct: +41 44 586 6450 
                  cell:   +41 79 422 6722
                  skype:  peterstev
                  
                  blog:   http://scrum-breakfast.com
                  
                • Charles Bradley - Scrum Coach CSM PSM I
                  ... I wrote some articles on this topic tonight: * Worst Practice: The Sprint Review as a Signoff Meeting * Executive Summary - The Sprint Review * Tips for a
                  Message 8 of 9 , Apr 13, 2011
                  • 0 Attachment
                    > Yes. Using the demo as an acceptance test means that the team does
                    > not know what's done until it is too late.

                    I wrote some articles on this topic tonight:
                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/



                  Your message has been successfully submitted and would be delivered to recipients shortly.