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

Re: [scrumdevelopment] Re: "Stories Too Big" Scrum Anti-pattern: what do you think about the effectiveness of the "now standard" format for a User Story?

Expand Messages
  • Ron Jeffries
    Hello, Roy. On Tuesday, November 23, 2010, at 10:40:15 PM, you ... Snarky, perhaps, Cynical. ... Yes. Just as it is impertinent for people who do something
    Message 1 of 56 , Nov 24, 2010
    • 0 Attachment
      Hello, Roy. On Tuesday, November 23, 2010, at 10:40:15 PM, you
      wrote:

      > "conventional, last century analysis"? ... now that is a low
      > blow, Ron, and I would suggest a rather foolish thing to say.

      Snarky, perhaps, Cynical.
      >
      > But, OK, let's agree that my few little words on a //story card//
      > will NEVER be considered a User Story. Given I didn't coin the
      > term originally, it is somewhat impertinent of me to try to define
      > it differently.

      Yes. Just as it is impertinent for people who do something ... meet
      every day, for example ... to say that they have been doing Scrum
      since 1942 or whatever.

      > But, I gotta tell ya, my conventional last-century analysis, old
      > fashioned as it might be, was highly successful, such that the
      > client was truly surprised, and told me that tis was the first
      > time ever that they had had a new development work on Day 1. This
      > did not surprise me, because it had worked on every occasion of a
      > demonstration from an iteration, so Day 1 was just another
      > successful end to an iteration.

      I don't imagine anyone here would argue that your conventional last-
      century analysis cannot work. We just don't recommend it. We think,
      for example, that a full analysis is wasteful if the customer comes
      up with new ideas later, as they always do. We think it is wasteful
      if some of what they asked for does not get done because they change
      their mind. We think it is risky if it drives teams to design too
      much, and to build too much, for what is going to be released. We
      think analysis should be an all the time activity, not an up front
      one.

      That's not to say that your way won't work for you. It's not to say
      that it won't work for your students. I have not worked with your
      students as far as I know. I have, however, worked with ex-students
      who have been taught this waterfall thinking, and by and large they
      are not as effective doing it as they would be in a more Agile
      style.

      But for all I know, what you teach is just so much better than Scrum
      and Agile that we should all pack up and go home.

      Doesn't matter. What you teach is not what Scrum and Agile teach. We
      should be clear about that. We should not redefine Scrum to be what
      Roy teaches. We should say, "Oh, wow, look! RoyDevelopment kicks
      Scrum's butt. Let's all teach RoyDevelopment from now on."

      > But, as I said before, I will cease debating the exactness and
      > properness of What is a User Story? That has failed to bring any
      > light to the heat, I would suggest (although other interested
      > observers may have learned somethingn of value).

      I hope we always learn from digging into the ideas.
      >
      > However, my brief research on the matter reveals some interesting definitions:

      > A user story is one or more sentences in the everyday or business
      > language of the user that captures what the user wants to
      > achieve.(http://en.wikipedia.org/wiki/User_story)
      > A good way to think about a user story is that it is a reminder
      > to have a conversation with your customer ... which is another way
      > to say it's a reminder to do some just-in-time analysis. In
      > short, user stories are very slim and high-level requirements
      > artifacts. (http://www.agilemodeling.com/artifacts/userStory.htm)
      > the USER STORY is indeed a narrative that a user tells from her
      > own perspective. (http://c2.com/cgi/wiki?UserStory)
      > A good story should be something you could explain on an elevator
      > in 30 seconds or so to a team member.
      > (http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html)
      >
      > I must say that I had all these sort of descriptions in my mind
      > when I coined my obviously faulty definition.
      >
      "The devil can quote scripture to his own purpose." :) The term
      "Story" can certainly be used as a shorthand for "the multiple
      person-day work that has to be done to satisfy the customer".

      We look at the story board, point at a card, and say "I worked on
      this yesterday." Someone in the back says "Which one is that". We
      say "The one about online enrollment passwords."

      These are all metaphors for what we actually do.


      Ron Jeffries
      www.XProgramming.com
      Confidence has nothing to do with perfection.
      It has to do with a quality of deep self-acceptance
      that leads us to do things in a masterful way,
      as it allows us to speak our mind and our hearts. -- Agapi Stassinopoulos
    • Ron Jeffries
      Hello, Roy. On Tuesday, November 23, 2010, at 10:40:15 PM, you ... Snarky, perhaps, Cynical. ... Yes. Just as it is impertinent for people who do something
      Message 56 of 56 , Nov 24, 2010
      • 0 Attachment
        Hello, Roy. On Tuesday, November 23, 2010, at 10:40:15 PM, you
        wrote:

        > "conventional, last century analysis"? ... now that is a low
        > blow, Ron, and I would suggest a rather foolish thing to say.

        Snarky, perhaps, Cynical.
        >
        > But, OK, let's agree that my few little words on a //story card//
        > will NEVER be considered a User Story. Given I didn't coin the
        > term originally, it is somewhat impertinent of me to try to define
        > it differently.

        Yes. Just as it is impertinent for people who do something ... meet
        every day, for example ... to say that they have been doing Scrum
        since 1942 or whatever.

        > But, I gotta tell ya, my conventional last-century analysis, old
        > fashioned as it might be, was highly successful, such that the
        > client was truly surprised, and told me that tis was the first
        > time ever that they had had a new development work on Day 1. This
        > did not surprise me, because it had worked on every occasion of a
        > demonstration from an iteration, so Day 1 was just another
        > successful end to an iteration.

        I don't imagine anyone here would argue that your conventional last-
        century analysis cannot work. We just don't recommend it. We think,
        for example, that a full analysis is wasteful if the customer comes
        up with new ideas later, as they always do. We think it is wasteful
        if some of what they asked for does not get done because they change
        their mind. We think it is risky if it drives teams to design too
        much, and to build too much, for what is going to be released. We
        think analysis should be an all the time activity, not an up front
        one.

        That's not to say that your way won't work for you. It's not to say
        that it won't work for your students. I have not worked with your
        students as far as I know. I have, however, worked with ex-students
        who have been taught this waterfall thinking, and by and large they
        are not as effective doing it as they would be in a more Agile
        style.

        But for all I know, what you teach is just so much better than Scrum
        and Agile that we should all pack up and go home.

        Doesn't matter. What you teach is not what Scrum and Agile teach. We
        should be clear about that. We should not redefine Scrum to be what
        Roy teaches. We should say, "Oh, wow, look! RoyDevelopment kicks
        Scrum's butt. Let's all teach RoyDevelopment from now on."

        > But, as I said before, I will cease debating the exactness and
        > properness of What is a User Story? That has failed to bring any
        > light to the heat, I would suggest (although other interested
        > observers may have learned somethingn of value).

        I hope we always learn from digging into the ideas.
        >
        > However, my brief research on the matter reveals some interesting definitions:

        > A user story is one or more sentences in the everyday or business
        > language of the user that captures what the user wants to
        > achieve.(http://en.wikipedia.org/wiki/User_story)
        > A good way to think about a user story is that it is a reminder
        > to have a conversation with your customer ... which is another way
        > to say it's a reminder to do some just-in-time analysis. In
        > short, user stories are very slim and high-level requirements
        > artifacts. (http://www.agilemodeling.com/artifacts/userStory.htm)
        > the USER STORY is indeed a narrative that a user tells from her
        > own perspective. (http://c2.com/cgi/wiki?UserStory)
        > A good story should be something you could explain on an elevator
        > in 30 seconds or so to a team member.
        > (http://www.extremeplanner.com/blog/2006/01/writing-good-user-stories.html)
        >
        > I must say that I had all these sort of descriptions in my mind
        > when I coined my obviously faulty definition.
        >
        "The devil can quote scripture to his own purpose." :) The term
        "Story" can certainly be used as a shorthand for "the multiple
        person-day work that has to be done to satisfy the customer".

        We look at the story board, point at a card, and say "I worked on
        this yesterday." Someone in the back says "Which one is that". We
        say "The one about online enrollment passwords."

        These are all metaphors for what we actually do.


        Ron Jeffries
        www.XProgramming.com
        Confidence has nothing to do with perfection.
        It has to do with a quality of deep self-acceptance
        that leads us to do things in a masterful way,
        as it allows us to speak our mind and our hearts. -- Agapi Stassinopoulos
      Your message has been successfully submitted and would be delivered to recipients shortly.