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

Re: [scrumdevelopment] User story help

Expand Messages
  • Bret Wortman
    In discussing the story with our PO, it was determined that it should be deleted, not just prioritized to the bottom. Maybe a bit extreme, but it also made
    Message 1 of 9 , Jan 19, 2012
    • 0 Attachment
      In discussing the story with our PO, it was determined that it should be deleted, not just prioritized to the bottom. Maybe a bit extreme, but it also made rewriting unnecessary. 


      Bret

      On Jan 19, 2012, at 11:08 AM, Steve Ropa <theropas@...> wrote:

       

      I think Ron is absolutely right.

       

      If I *were* to rephrase it, I might say something like “Client developers need feedback as to the amount of traffic they are hitting the system with.  They should be warned if they are hitting the system too hard, so they can take corrective measures.”

       

      Even so, the key is that the team understands what is needed.

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
      Sent: Wednesday, January 18, 2012 12:07 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] User story help

       

       

      Hi Bret,

       

      On Jan 12, 2012, at 8:31 AM, Bret Wortman wrote:



      "As a client developer, I need to know that my program floods another
      system with requests at too high a rate, so that I can redesign my system
      for a more reasonable usage rate."

      I know what they're going for is a way to get feedback from our
      infrastructure that they're banging on a remote system too hard, but I'm
      not exactly sure how to rewrite the user story to reflect that. Maybe I'm
      just too tired or uncreative this morning. Any ideas?

       

      If everyone understands what is really needed, there is no need to rewrite the story.


      Ron Jeffries

      I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

       

    • Pierre Neis
      It seems that your story is not INVEST! 1. rewrite 2. is it a virtual user? If no, then go ask him/her 3. if it s unclear, then it s not urgent 4. which are
      Message 2 of 9 , Jan 20, 2012
      • 0 Attachment
        It seems that your story is not INVEST!

        1. rewrite
        2. is it a virtual user? If no, then go ask him/her
        3. if it's unclear, then it's not urgent
        4. which are the acceptance criteria of the US?

        MAKE AN ELEFANT SASHIMI!


        Pierre E.  NEIScsp

        PMO Advisor @ coPROcess S.A. 
        │ Scrum & Lean Coach   

        M: +352 / 661 727 867  - Skype: pierre.neis  
        Meet with me: http://meetwith.me/pierreneis


        Owner of The "
        Product Owner's Help Desk"

        Blogger Twitter LinkedIn SlideShare
        Contact me: Google Talk pierreneis@... Skype pierre.neis
        TwitterLatest tweet: Agile Ruined My Life http://t.co/jxNwQ6gs via @danielbmarkham Follow @elPedroMajor Reply Retweet   16:04 Jan-19


        On 19 January 2012 17:08, Steve Ropa <theropas@...> wrote:
         

        I think Ron is absolutely right.

         

        If I *were* to rephrase it, I might say something like “Client developers need feedback as to the amount of traffic they are hitting the system with.  They should be warned if they are hitting the system too hard, so they can take corrective measures.”

         

        Even so, the key is that the team understands what is needed.

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
        Sent: Wednesday, January 18, 2012 12:07 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] User story help

         

         

        Hi Bret,

         

        On Jan 12, 2012, at 8:31 AM, Bret Wortman wrote:



        "As a client developer, I need to know that my program floods another
        system with requests at too high a rate, so that I can redesign my system
        for a more reasonable usage rate."

        I know what they're going for is a way to get feedback from our
        infrastructure that they're banging on a remote system too hard, but I'm
        not exactly sure how to rewrite the user story to reflect that. Maybe I'm
        just too tired or uncreative this morning. Any ideas?

         

        If everyone understands what is really needed, there is no need to rewrite the story.


        Ron Jeffries

        I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

         


      • Steve Ropa
        That was a really good choice. The odds are good that, if you need the story again, you will find a better way to write it the next time. That s how I
        Message 3 of 9 , Feb 1, 2012
        • 0 Attachment

          That was a really good choice.  The odds are good that, if you need the story again, you will find a better way to write it the next time.  That’s how I approach my code, too.

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Bret Wortman
          Sent: Thursday, January 19, 2012 10:20 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] User story help

           

           

          In discussing the story with our PO, it was determined that it should be deleted, not just prioritized to the bottom. Maybe a bit extreme, but it also made rewriting unnecessary. 

           

          Bret


          On Jan 19, 2012, at 11:08 AM, Steve Ropa <theropas@...> wrote:

           

          I think Ron is absolutely right.

           

          If I *were* to rephrase it, I might say something like “Client developers need feedback as to the amount of traffic they are hitting the system with.  They should be warned if they are hitting the system too hard, so they can take corrective measures.”

           

          Even so, the key is that the team understands what is needed.

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
          Sent: Wednesday, January 18, 2012 12:07 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] User story help

           

           

          Hi Bret,

           

          On Jan 12, 2012, at 8:31 AM, Bret Wortman wrote:

           

          "As a client developer, I need to know that my program floods another
          system with requests at too high a rate, so that I can redesign my system
          for a more reasonable usage rate."

          I know what they're going for is a way to get feedback from our
          infrastructure that they're banging on a remote system too hard, but I'm
          not exactly sure how to rewrite the user story to reflect that. Maybe I'm
          just too tired or uncreative this morning. Any ideas?

           

          If everyone understands what is really needed, there is no need to rewrite the story.


          Ron Jeffries

          I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

           

        • JackM
          Completely agree with Charles and Ron. What s most important are the acceptance test criteria. Focus on getting that right. Make sure you come to agreement in
          Message 4 of 9 , Feb 1, 2012
          • 0 Attachment
            Completely agree with Charles and Ron.

            What's most important are the acceptance test criteria. Focus on getting that right. Make sure you come to agreement in the team setting preferably with the stakeholder or customer present.

            Happy scrumming
            Jack
            www.agilebuddy.com

            --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
            >
            >
            > I concur with Ron, but from the description you wrote, it's
            > unclear to me what the infrastructure is supposed to when this happens. 
            > Sure, it needs to give "feedback", but the user story is not complete
            > and ready for development IMO until you know what this feedback is... Is
            > it a 503 - Server Unavailable?  Is it an exception being thrown?  Is it
            > a service you can call that will tell you if you're overloading the
            > infrastructure system?
            >
            > As your story is written, it sounds like it's written by someone outside
            > of the system, and that's perfectly fine as an early stage user story--
            > but the user story is not complete yet because you haven't written
            > actionable confirmations(aka acceptance tests, story tests) -- or at
            > least you haven't told us what they are. 
            >
            >
            > However,
            > through the process of backlog grooming or some other interaction (maybe backlog grooming plus a little back and forth with the stakeholder), I
            > would try to come to some agreement with the requester as to what, more
            > specifically, that means.  My guess is it would be much easier to write
            > your story more specifically in that case if you so desired. 
            >
            >
            > On the flip side, I only like the user story template as a start, and
            > usually only for stakeholders -- and even then I find conversing better
            > than trying to re-word the perfect sentence.  I like to, after
            > conversations between the stakeholder, PO, and Dev Team (through backlog grooming or other interaction), lighten the user story title(converting the "As a..." sentence to something shorter and easier to quickly write on a card or sticky note) and instead focus on the acceptance tests.
            >
            > For instance, after said conversations, I might lighten the story to:
            >
            > User Story Description(used to be "As a client developer..."): Notify client upon excessive requests
            > <conversation, conversation... resulting in...>
            > Acceptance Tests:
            > 1.  Test that, when a client makes more than 30 "read only" type requests
            > within 3 seconds, a 503 - Server Unavailable error is returned.
            > 2.  Test that, when a client makes more than 10 "update" type requests within 3 seconds, a 503 - Server Unavailable is returned.
            >
            > At this point, and assuming minor details are filled in verbally, the story is ready for development.
            >
            >
            > To me, spending any more than about 120 "man seconds" on *re*-writing an "As a..."
            > sentence is a bad smell.  Instead, have conversations and come to an
            > agreement on specific acceptance tests.  The "As a..." template was not
            > in the original User Story practice anyway.  It was added later, and
            > IMO, it only has ROI in very special contexts.
            >
            >  
            > -------
            > Charles Bradley
            > http://www.ScrumCrazy.com
            >
            >
            >
            > >________________________________
            > > From: RonJeffries <ronjeffries@...>
            > >To: scrumdevelopment@yahoogroups.com
            > >Sent: Wednesday, January 18, 2012 12:06 PM
            > >Subject: Re: [scrumdevelopment] User story help
            > >
            > >
            > >
            > >
            > >
            > >Hi Bret,
            > >
            > >
            > >On Jan 12, 2012, at 8:31 AM, Bret Wortman wrote:
            > >
            > >"As a client developer, I need to know that my program floods another
            > >>system with requests at too high a rate, so that I can redesign my system
            > >>for a more reasonable usage rate."
            > >>
            > >>I know what they're going for is a way to get feedback from our
            > >>infrastructure that they're banging on a remote system too hard, but I'm
            > >>not exactly sure how to rewrite the user story to reflect that. Maybe I'm
            > >>just too tired or uncreative this morning. Any ideas?
            > >
            > >If everyone understands what is really needed, there is no need to rewrite the story.
            > >
            > >
            > >Ron Jeffries
            > >www.XProgramming.com
            > >I'm not bad, I'm just drawn that way.  -- Jessica Rabbit
            > >
            > >
            > >
            > >
            > >
            > >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.