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

User Stories, APIs and data feeds

Expand Messages
  • Ram Srinivasan
    We all know the template of a user story As a I want
    Message 1 of 4 , Jul 8 8:40 PM
    • 0 Attachment
      We all know the template of a user
      story<http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template>

      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<http://en.wikipedia.org/wiki/Computer_reservations_system>)
      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


      [Non-text portions of this message have been removed]
    • Matteo Vaccari
      ... Hello Ram, one alternative format that you might find useful is When We want So that Matteo [Non-text
      Message 2 of 4 , Jul 8 11:16 PM
      • 0 Attachment
        On Tue, Jul 9, 2013 at 5:40 AM, Ram Srinivasan <vasan.ram@...> wrote:

        > We all know the template of a user
        > story<
        > http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template
        > >
        >
        > 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<http://en.wikipedia.org/wiki/Computer_reservations_system>)
        > 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?
        >
        >
        Hello Ram,

        one alternative format that you might find useful is

        When <event happens>
        We want <something to happen>
        So that <benefit>

        Matteo


        [Non-text portions of this message have been removed]
      • Ron Jeffries
        Hi Ram, ... A user story has three parts according to us guys what first used them: the card, upon which something is typically written, the conversation,
        Message 3 of 4 , Jul 9 5:09 AM
        • 0 Attachment
          Hi Ram,

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

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


          A user story has three parts according to us guys what first used them: the card, upon which something is typically written, the conversation, which is what gets the programmers and the customer on the same page, and the confirmation, which is a clear statement of the acceptance conditions for the story, and is the basis for its automated acceptance tests.

          As such, it doesn't matter a bit what you write on the card, much less what syntax you use. The card is there to remind everyone what they are talking about. You could call the story Marie and it would work just as well.

          The famous as-a format is training wheels. If it has value, it is in helping people, when coming up with stories, to think about who wants the feature and why.

          Now your question remains important, and a number of respondents have brought this out. The temptation to say "as a computer, I want RAM in me, so that I can remember stuff" is a sign that we do not understand the business purpose of something, in your case an API.

          The story can be any phrasing we want but we need to become clear what human user of the software wants it, and why. We often call that "business purpose" or "business value".

          Once we understand the business value, we're on a good path. So long as we do not, we're off the road entirely.

          Ron Jeffries
          www.XProgramming.com
          Sometimes I give myself admirable advice, but I am incapable of taking it.
          -- Mary Wortley Montagu





          [Non-text portions of this message have been removed]
        • Ram Srinivasan
          It makes sense Ron, thanks very much. Training wheels format is not *the* template for user stories. Thanks, Ram ... [Non-text portions of this message have
          Message 4 of 4 , Jul 9 7:58 PM
          • 0 Attachment
            It makes sense Ron, thanks very much. Training wheels format is not *the*
            template for user stories.

            Thanks,
            Ram


            On Tue, Jul 9, 2013 at 8:09 AM, Ron Jeffries <ronjeffries@...> wrote:

            > **
            >
            >
            > Hi Ram,
            >
            >
            > On Jul 8, 2013, at 11:40 PM, Ram Srinivasan <vasan.ram@...> wrote:
            >
            > > 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?
            >
            > A user story has three parts according to us guys what first used them:
            > the card, upon which something is typically written, the conversation,
            > which is what gets the programmers and the customer on the same page, and
            > the confirmation, which is a clear statement of the acceptance conditions
            > for the story, and is the basis for its automated acceptance tests.
            >
            > As such, it doesn't matter a bit what you write on the card, much less
            > what syntax you use. The card is there to remind everyone what they are
            > talking about. You could call the story Marie and it would work just as
            > well.
            >
            > The famous as-a format is training wheels. If it has value, it is in
            > helping people, when coming up with stories, to think about who wants the
            > feature and why.
            >
            > Now your question remains important, and a number of respondents have
            > brought this out. The temptation to say "as a computer, I want RAM in me,
            > so that I can remember stuff" is a sign that we do not understand the
            > business purpose of something, in your case an API.
            >
            > The story can be any phrasing we want but we need to become clear what
            > human user of the software wants it, and why. We often call that "business
            > purpose" or "business value".
            >
            > Once we understand the business value, we're on a good path. So long as we
            > do not, we're off the road entirely.
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Sometimes I give myself admirable advice, but I am incapable of taking it.
            > -- Mary Wortley Montagu
            >
            >
            > [Non-text portions of this message have been removed]
            >
            >
            >


            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.