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

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

Expand Messages
  • Cass Dalton
    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:


      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

      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"?


    • Show all 14 messages in this topic