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

Modifying User Stories

Expand Messages
  • marktuckerus2000
    We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality
    Message 1 of 6 , Apr 7 7:47 AM
    View Source
    • 0 Attachment
      We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality that forces user stories to be modified. How do users in Agile world handle this? Is there any standard one need to follow before keeping User Stories in-sync with the modifications to the functionality in the last minute?

      Any help is great.
    • Steven Gordon
      Are they wanting to modify stories that have already been implemented or stories that have not yet been implemented? Stories that have already been implemented
      Message 2 of 6 , Apr 11 10:41 AM
      View Source
      • 0 Attachment
        Are they wanting to modify stories that have already been implemented or stories that have not yet been implemented?

        Stories that have already been implemented and accepted cannot be modified, but new stories can be written to indicate what changes are desired.

        Stories that have not yet been implemented can just be replaced with new stories will very little impact.

        User stories are supposed to be independent enough that they do not depend on other stories, so there should be no problem with replacing unimplemented stories or adding change stories for already implemented stories.  If stories seem interdependent, then perhaps they are horizontal (aligned with architectural layers or components).  Stories that are vertical (aligned with visible functionality) tend to be independent.

        SteveG

        On Wed, Apr 7, 2010 at 7:47 AM, marktuckerus2000 <marktuckerus2000@...> wrote:
         

        We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality that forces user stories to be modified. How do users in Agile world handle this? Is there any standard one need to follow before keeping User Stories in-sync with the modifications to the functionality in the last minute?

        Any help is great.


      • Martin Kearns
        Mark You need to have some flexibility within the sprint / iteration to accomodate minor changes etc. So how do set the boundary to what can be accomodated. I
        Message 3 of 6 , Apr 11 2:47 PM
        View Source
        • 0 Attachment

          Re: [agile-testing] Modifying User Stories

          Mark

          You need to have some flexibility within the sprint / iteration to accomodate minor changes etc.

          So how do set the boundary to what can be accomodated. I use the sprint goal as my first boundary, if the additional context is beyond the sprint goal it is not included. We also love setting last responsible moments for accepting change.

          I hope this helps you. Let me know if you have any questions.

          Regards,
          Martin.

          ----- Original Message -----
          From: agile-testing@yahoogroups.com <agile-testing@yahoogroups.com>
          To: agile-testing@yahoogroups.com <agile-testing@yahoogroups.com>
          Sent: Thu Apr 08 00:47:07 2010
          Subject: [agile-testing] Modifying User Stories

           

          We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality that forces user stories to be modified. How do users in Agile world handle this? Is there any standard one need to follow before keeping User Stories in-sync with the modifications to the functionality in the last minute?

          Any help is great.





          ______________________________________________________________________
          This email has been scanned by the MessageLabs Email Security System.
          For more information please visit http://www.messagelabs.com/email
          ______________________________________________________________________

          Martin Kearns Principal Consultant
          Level 17 / 120 Collins St Melbourne Vic 3000 Australia
          T +61 3 9670 7790 F +61 3 9670 6663 M +61 437 676 959
          www.renewtek.com
          martin.kearns@...

          Please consider the environment before printing this email or attachments


          ______________________________________________________________________
          This email has been scanned by the MessageLabs Email Security System.
          For more information please visit http://www.messagelabs.com/email
          ______________________________________________________________________
        • Rob Park
          1. Write as little as possible on the user story card . (In other words, try not to maintain some large documentation base of what the app does.) 2. Manage
          Message 4 of 6 , Apr 11 8:38 PM
          View Source
          • 0 Attachment
            1. Write as little as possible on the user story "card". (In other words, try not to maintain some large documentation base of what the app does.)
            2. Manage requirements (or story details) in an executable format. (E.g. Given/When/Then, FitNesse, etc)

            -- 
            Rob
            --
            http://agileintention.blogspot.com
            http://twitter.com/robpark
            http://leandog.com

            On Wed, Apr 7, 2010 at 2:47 PM, marktuckerus2000 <marktuckerus2000@...> wrote:
             

            We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality that forces user stories to be modified. How do users in Agile world handle this? Is there any standard one need to follow before keeping User Stories in-sync with the modifications to the functionality in the last minute?

            Any help is great.



          • chrs_mcmhn
            ... Remember one of the four values of the agile manifesto is responding to change . One of the 12 principles is to welcome changing requirements, even late
            Message 5 of 6 , Apr 12 6:16 AM
            View Source
            • 0 Attachment
              --- In agile-testing@yahoogroups.com, "marktuckerus2000" <marktuckerus2000@...> wrote:
              >
              > We are using Agile methodology for our software development. We are almost there in Production and now stakeholders are requesting changes to the functionality that forces user stories to be modified. How do users in Agile world handle this? Is there any standard one need to follow before keeping User Stories in-sync with the modifications to the functionality in the last minute

              Remember one of the four values of the agile manifesto is "responding to change". One of the 12 principles is to "welcome changing requirements, even late in development."

              That is one reason to use iterations, so that no story is more than one iteration away from being implemented. So if the Customer wants to change the way the existing software works, then the Customer should be allowed to create a story to have the team do that.

              That said, such changes can become pathological. I worked on one team for a while where the Customers simply never made up their minds how they wanted the features to function. So the team re-wrote the same features iteration after iteration.

              In theory, this kind of thing should not make an agile team unhappy. If the Customer wants changes, the Customer should be able to get changes. But if the team feels that they are simply running in a treadmill re-working the same things over and over again, that might be an issue to resolve in a retrospective.
            • George Dinwiddie
              Mark, ... What Rob said! You will be amazed at how easily this solves your problem. - George -- ... * George Dinwiddie *
              Message 6 of 6 , Apr 12 7:07 AM
              View Source
              • 0 Attachment
                Mark,

                Rob Park wrote:
                >
                >
                > 1. Write as little as possible on the user story "card". (In other
                > words, try not to maintain some large documentation base of what the app
                > does.)
                > 2. Manage requirements (or story details) in an executable format. (E.g.
                > Given/When/Then, FitNesse, etc)

                What Rob said! You will be amazed at how easily this solves your problem.

                - George

                --
                ----------------------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------------------
              Your message has been successfully submitted and would be delivered to recipients shortly.