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

Re: [scrumdevelopment] User Stories, APIs and data feeds

Expand Messages
  • Adam Sroka
    I agree with Ron s assessment of the template. The main problem with it is the misconception that any statement that can be coerced into that format is
    Message 1 of 14 , Jul 12, 2013
    • 0 Attachment
      I agree with Ron's assessment of the template. The main problem with it is the misconception that any statement that can be coerced into that format is automatically a story. That said, the template does imply three questions that you should be able to answer: who is this story valuable to? What are they trying to accomplish? And, how do they intend to go about it?

      The first question is the most important one, because you need to know who to have a conversation with. The other details can change once you have that conversation. If you can't figure out who the story is valuable to and why then you should probably work on something else until you get an answer. 

      On the other hand, if you know who the story is valuable to their name doesn't have to be on the card per se. It can be useful to write it down if you have a system with a diverse group of users with competing or unrelated needs, but it's not a requirement. 


      On Thu, Jul 11, 2013 at 10:53 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
       

      Cass,

      Agreed that there are a couple of "small cases" where the template helps -- for a little while.  The vast majority of cases I've seen, it hurts, either because people spend too much time trying to force fit the template, or get into this mode that the template/sentence *IS* a user story.  Thinking the template/sentence *IS* a user story is the biggest trap of all IMO... something I wrote about several years back:
      http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/  (See trap #1 and #8)

      Btw, I fell into many of those traps -- which is why I can write so freely and well about them!  :-)  Our fellow lister and co-inventor of User Stories Ron Jeffries "schooled" me on many a thread... forever grateful for that man's patience.

      -------
      Charles Bradley
      Professional Scrum Trainer
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Cass Dalton <cassdalton73@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wednesday, July 10, 2013 12:24 PM
      Subject: Re: [scrumdevelopment] User Stories, APIs and data feeds



      I always saw the "As a... I want... Because..." as "training wheels" for learning user stories.  Once you learn how to ride, they get in the way.  But they are really helpful to learn how to ride a bike in the first place.
      The template mentioned by the OP may get in the way when you're a seasoned agile practitioner, but when you are first learning about user stories, especially if you're coming from a "The system shall..." culture, being forced to specify the user, specify the desired user's action (vs a desired system characteristic), and specify WHY the user wants to perform that action really helps get you out of the requirements mentality.


      On Tue, Jul 9, 2013 at 3:48 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
       
      Ram,

      What you mentioned is *a* user story template, not "the template of a user story".  The user story practice itself does not require or even suggest the template strategy.  IMO, the template itself most often harms the true intention of the user story practice, but that's probably off topic.

      Having said that, why do you need to use the template?  It sounds like maybe you're having trouble expressing the business need in business terms, which is pretty smelly in its own right... Why is this?  What kind of waste is being created by not understanding the business intention?  Where is the PO in all of this?  Why doesn't he/she understand the business needs?

      Yes, the end user themselves may not understand the underlying value of the feed... but someone should... or you shouldn't be wasting the company's money developing features of suspect value. 

      I don't think that the root problem is with the template or the user story practice.

      -------
      Charles Bradley
      Professional Scrum Trainer
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Ram Srinivasan <vasan.ram@...>
      To: "scrumalliance@..." <scrumalliance@...>; "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>; "extremeprogramming@yahoogroups.com" <extremeprogramming@yahoogroups.com>; "leanagile@yahoogroups.com" <leanagile@yahoogroups.com>
      Sent: Monday, July 8, 2013 9:40 PM
      Subject: [scrumdevelopment] User Stories, APIs and data feeds



      We all know the template of a user story

      As a <role>
      I want <feature>
      So that <benefit> 

      or something similar.

      It is straightforward if the "consumer" of a feature is well defined (say a shopper in an e-commerce site). This format also appeals better when we are asking developers to develop a "thin" vertical slice. 

      Consider a trading system or data feed/api (like GDS) where the goal of the application (say API-app) is to consolidate different data and give it to other third party "systems" ( which can be consumed in a multitude of ways by different users of different "systems". These third party systems are not within the same organizational boundaries).  The end user may not even realize the benefit of the underlying API/feed (from API-app)  because the "system" obscures the presence/absence of a particular feed/data. The development team which develop the feeds/apis can only make a vague guess on who might be using the feeds/apis and the benefits that they may be looking for. 

      Would it still make sense to write user stories (for API-app) in "As a <role> ..." format, where role is the ultimate end user of an api/feed (marshalled through an intermediate "system")?  What would be the benefit? And drawback?

      What other approaches would make more sense when the actual consumer of a particular data feed/api is separated from the teams (generating the feeds/apis) by multiple "value streams"?

      Thanks,
      Ram











    • Dinesh Sharma
      I wonder who is the user of a technical user story ;) Sent from my iPhone
      Message 2 of 14 , Jul 12, 2013
      • 0 Attachment
        I wonder who is the user of a technical 'user story' ;)

        Sent from my iPhone

        On 9 Jul 2013, at 18:50, Prashant Pund <pundprashant@...> wrote:

         

        The stories can be of 2 types; User story and Technical story. User stories can be written using the format mentioned here. The users can be any actors,  human or another system/application.  A Technical story is what perhaps mentioned by Jeff here.  The format of the same need not be " as a...". rather it could be like " implement or develop. .. component/service/algorithm. ..so that. .".
        Prashant Pund
        Agile Coach,
        AgileSoft Methodologies

        On Jul 9, 2013 9:41 PM, "Jeff Sutherland" <jeff.sutherland@...> wrote:
         

        We have this API example in companies building compilers. For example, Pegasystems has a domain specific language compiler that is used by all developement teams to build tools (features) for large IT enterprise shops to build applications for the business. There is a third level where tools are assembled into framework for domains (healthcare, insurance, financials, etc.) so you could use the entire tool set to run American Express for example.

        The leader of the compiler group (multiple Scrum teams) is a technical product owner on the product owner team for the company and his job is to produce the language APIs needed for development in the language. So his Product Backlog is API enhancement requests from the tool teams that support user stories where the user is an enterprise customer building a software application to run the company.

        --
        Jeff Sutherland, Ph.D. 
        CEO, Scrum Inc.

      • Ahmed Hammad
        I also wonder about it. IMHO, I would rather name it technical task or just task and keep the word story for valuable functionality to product owner.
        Message 3 of 14 , Jul 16, 2013
        • 0 Attachment
          I also wonder about it.

          IMHO, I would rather name it technical task or just task and keep the word "story" for valuable functionality to product owner.

          Regards,
          Ahmed Hammad



          On Jul,12 2013, at 6:40 PM, Dinesh Sharma <dinesh_shama@...> wrote:

           

          I wonder who is the user of a technical 'user story' ;)

          Sent from my iPhone

          On 9 Jul 2013, at 18:50, Prashant Pund <pundprashant@...> wrote:

           

          The stories can be of 2 types; User story and Technical story. User stories can be written using the format mentioned here. The users can be any actors,  human or another system/application.  A Technical story is what perhaps mentioned by Jeff here.  The format of the same need not be " as a...". rather it could be like " implement or develop. .. component/service/algorithm. ..so that. .".
          Prashant Pund
          Agile Coach,
          AgileSoft Methodologies

          On Jul 9, 2013 9:41 PM, "Jeff Sutherland" <jeff.sutherland@...> wrote:
           

          We have this API example in companies building compilers. For example, Pegasystems has a domain specific language compiler that is used by all developement teams to build tools (features) for large IT enterprise shops to build applications for the business. There is a third level where tools are assembled into framework for domains (healthcare, insurance, financials, etc.) so you could use the entire tool set to run American Express for example.

          The leader of the compiler group (multiple Scrum teams) is a technical product owner on the product owner team for the company and his job is to produce the language APIs needed for development in the language. So his Product Backlog is API enhancement requests from the tool teams that support user stories where the user is an enterprise customer building a software application to run the company.

          --
          Jeff Sutherland, Ph.D. 
          CEO, Scrum Inc.




        • Cass Dalton
          More importantly, where s the end user or customer value of the technical story. If you can find it, then you can write it as a user story, If you can t, why
          Message 4 of 14 , Jul 16, 2013
          • 0 Attachment
            More importantly, where's the end user or customer value of the technical story.  If you can find it, then you can write it as a user story,  If you can't, why are you using the customer's money to do it?


            On Fri, Jul 12, 2013 at 12:40 PM, Dinesh Sharma <dinesh_shama@...> wrote:
             

            I wonder who is the user of a technical 'user story' ;)

            Sent from my iPhone

            On 9 Jul 2013, at 18:50, Prashant Pund <pundprashant@...> wrote:

             

            The stories can be of 2 types; User story and Technical story. User stories can be written using the format mentioned here. The users can be any actors,  human or another system/application.  A Technical story is what perhaps mentioned by Jeff here.  The format of the same need not be " as a...". rather it could be like " implement or develop. .. component/service/algorithm. ..so that. .".
            Prashant Pund
            Agile Coach,
            AgileSoft Methodologies

            On Jul 9, 2013 9:41 PM, "Jeff Sutherland" <jeff.sutherland@...> wrote:
             

            We have this API example in companies building compilers. For example, Pegasystems has a domain specific language compiler that is used by all developement teams to build tools (features) for large IT enterprise shops to build applications for the business. There is a third level where tools are assembled into framework for domains (healthcare, insurance, financials, etc.) so you could use the entire tool set to run American Express for example.

            The leader of the compiler group (multiple Scrum teams) is a technical product owner on the product owner team for the company and his job is to produce the language APIs needed for development in the language. So his Product Backlog is API enhancement requests from the tool teams that support user stories where the user is an enterprise customer building a software application to run the company.

            --
            Jeff Sutherland, Ph.D. 
            CEO, Scrum Inc.


          • Ron Jeffries
            All, ... If some development effort has no value to the Product Owner, it should not be done. If it does have value to the Product Owner, it can be expressed
            Message 5 of 14 , Jul 17, 2013
            • 0 Attachment
              All,

              On Jul 16, 2013, at 4:40 PM, Ahmed Hammad <ahm507@...> wrote:

              IMHO, I would rather name it technical task or just task and keep the word "story" for valuable functionality to product owner.

              If some development effort has no value to the Product Owner, it should not be done.

              If it does have value to the Product Owner, it can be expressed in those terms, and should be.

              "Technical tasks" are a sign of Scrum immaturity, IMO.

              Ron Jeffries
              www.XProgramming.com
              Everything that needs to be said has already been said.
              But since no one was listening, everything must be said again. -- Andre Gide

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