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

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

Expand Messages
  • Cass Dalton
    90% of the time, there is still a human somewhere that wants to do something that is being enabled by the API. You may have to make a couple of steps to get
    Message 1 of 14 , Jul 9, 2013
    • 0 Attachment
      90% of the time, there is still a human somewhere that wants to do something that is being enabled by the API.  You may have to make a couple of steps to get from the API to an end user or customer need, but if you don't have an end user or customer need, who is paying for the work?


      On Mon, Jul 8, 2013 at 11:40 PM, Ram Srinivasan <vasan.ram@...> wrote:
       

      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


    • Jeff Sutherland
      We have this API example in companies building compilers. For example, Pegasystems has a domain specific language compiler that is used by all developement
      Message 2 of 14 , Jul 9, 2013
      • 0 Attachment
        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.
      • Prashant Pund
        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
        Message 3 of 14 , Jul 9, 2013
        • 0 Attachment

          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.
        • Charles Bradley - Professional Scrum Trai
          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
          Message 4 of 14 , Jul 9, 2013
          • 0 Attachment
            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





          • Kevin Callahan
            Ram, A couple of teams I work with have extensive API-based functionality; it is a challenge to know how to capture the what without getting too deeply into
            Message 5 of 14 , Jul 9, 2013
            • 0 Attachment
              Ram,

              A couple of teams I work with have extensive API-based functionality; it is a challenge to know how to capture the "what" without getting too deeply into the "how"

              To Charles' and others' point, having a high degree of clarity on *what* an end user would be able to observe in the application is one starting point, and will likely be broken down into several user stories of its own. If this question cannot be answered, then as Charles states, perhaps the business does not yet know enough about what it needs. Building software to vague needs delivers vague value; however the expense of producing it is certainly very clear.

              If you can get clarity on the "what", at some point you may find that you need more granularity to convey the behavior of the underlying systems, which are invisible to the user, or because of underlying complexity the human-centric stories are too large to confidently estimate. For this we've had success using roles that map onto the sub-systems, though retain a focus on behavior, not implementation details. That can be tricky for developers to initially wrap their heads around, at least it was for us.

              Also, there may be a point where to slice a backlog item thin enough, it may no longer easily fit into a user story, or a single user story covers multiple sprint backlog items.

              On a more technical note there are also a whole slew of engineering practices that will enable your teams and developers to more successfully work with external APIs, though my sense is that's another topic altogether.

              Anyhow, hope some of that is helpful...

              -k



              On Jul 9, 2013, at 3:48 PM, Charles Bradley - Professional Scrum Trainer and Coach 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







              Kevin Callahan
              Scrum Master & Agile Coach
              LiveWorld Inc.

              Mobile+1 (207) 691-2997
              Emailkcallahan@...
              Skypekevmocal
              Webwww.liveworld.com

              Follow UsFacebook Twitter LinkedIn



            • Cass Dalton
              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
              Message 6 of 14 , Jul 10, 2013
              • 0 Attachment
                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






              • Charles Bradley - Professional Scrum Trai
                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
                Message 7 of 14 , Jul 11, 2013
                • 0 Attachment
                  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










                • 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 8 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 9 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 10 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 11 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 12 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.