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

56983User Stories, APIs and data feeds

Expand Messages
  • Ram Srinivasan
    Jul 8, 2013
      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