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

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

Expand Messages
  • 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 1 of 4 , Jul 9, 2013
    • 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 2 of 4 , Jul 9, 2013
      • 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.