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

Re: User Stories Opinion

Expand Messages
  • JackM
    I d agree that emphasis should be placed on the confirmations and developing a good set of acceptance test criteria up front. Works really well for us. Jack
    Message 1 of 48 , Oct 6, 2010
    • 0 Attachment
      I'd agree that emphasis should be placed on the confirmations and developing a good set of acceptance test criteria up front. Works really well for us.

      Jack
      www.agilebuddy.com
      blog.agilebuddy.com

      --- In scrumdevelopment@yahoogroups.com, "charles_bradley_scrum_coach" <chuck-lists2@...> wrote:
      >
      >
      > Adam,
      >
      > > ...spend 70%+ of their time talking about estimates and reserving insufficient (in some cases no) time to have the conversation about what actually needs to be accomplished and how...
      >
      > I see this as two issues:
      > 1. Spending 70%+ of their time discussing estimates.
      > (Surely you don't mean 70% of their time in a sprint? -- Do you mean 70% of their time in a Sprint Planning Meeting? Can you clarify?)
      > 2. Failing to reserve sufficient time to have conversations.
      > I see this sometimes as well, and it's usually caused by so much time spent in the standard Sprint Timebox meetings that the last thing the team wants to do is schedule another meeting. But again, the root cause there is generally a failure to coach/facilitate by the ScrumMaster and/or the fact that a new team has gone all-in on Scrum and is still struggling with efficiency in the standard Sprint Timebox meetings.
      >
      > Steve,
      > > ...I think that's why I'm starting to join the "don't estimate them" crowd. One less thing to over analyze....
      >
      > If you don't estimate backlog items, then you're not doing Scrum at all, so you might as well stop pretending that your team is using Scrum, and come up with some other way of doing any kind of reasonable planning. I don't say this to be rude, just as a matter of fact. Much of Scrum is based on the idea that things can and must be estimated, whether it be backlog items or tasks. If you stop estimating, you're just not doing Scrum.
      >
      > If your team is really spending too much time over-analyzing estimates, then someone needs to raise the issue at a retro or the SM needs to recognize this and coach the team appropriately.
      >
      > I would encourage you both not to the throw the baby out with the bath water, though I do share many of your thoughts regarding pain around User Stories as they are described by the "forefathers" of User Stories.
      >
      > Ron(+ other readers),
      > if you're still reading, I didn't mean to butcher the 3 C's into "verbal and card". I guess what I was really trying to say is that the literature puts a lot of emphasis on the "Conversation" as a way to remember story details (vs. written documentation), and I believe this to be a very advanced agile concept. Noble and probably extremely efficient, but advanced, and newbies should be careful about thinking they can get to that ability overnight.
      >
      > I prefer to lead non advanced agile teams down the road of putting a lot of emphasis on "Confirmations"(Acceptance Tests/Criteria, COS, etc), which usually requires a fair amount of Conversation to get there anyway. I also encourage them to document the "Confirmations" at least at a conceptual level ("Test that....") so that everyone is on the same "page" in terms of how details will be implemented. (Of course, re-enforcing that the details are solely "the what", not "the how"). Once they get these concepts down, I usually encourage them to learn how to break stories down smaller and then eventually "go verbal" on some of the smaller stories.
      >
      > What I often see a lot with teams is a very big emphasis on the "Card" (as a planning token and or story description) part of the story, thus wasting a lot of time on the "As a <user>, I want...so that...". They may also talk some of the story out, but no one bothers to firm up the details by writing confirmations(whether they be conceptual/prose or acceptance tests). Some of the literature also seems to emphasize a lot of this, which is a shame.
      >
      > Of course, how do you do any of this with a PO that is mostly absent? But don't get me started on that.
      >
      > Charles
      >
      >
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, "Steve Ropa" <theropas@> wrote:
      > >
      > > Hi Adam,
      > >
      > > This is a great description of the "state of stories today". I have run into almost exactly the same issues in many shops. I think that's why I'm starting to join the "don't estimate them" crowd. One less thing to over analyze.
      > >
      > >
      > > From: Adam Sroka
      > > Sent: Sunday, October 03, 2010 2:59 PM
      > > To: scrumdevelopment@yahoogroups.com
      > > Subject: Re: [scrumdevelopment] Re: User Stories Opinion
      > >
      > >
      > >
      > > User stories predate Mike Cohn's book by at least several years. They might predate XP as well (Many of the XP practices do) but I'm not sure about that. What Mike added to the conversation was the notion that Stories were a generally useful Agile concept that could be applied outside of XP (e.g. in Scrum.)
      > >
      > >
      > >
      > > Stories are misapplied by most Scrum teams that I encounter in principally two ways:
      > >
      > >
      > > 1) There is confusion around the notion that "everything is a story." We still need to think about what is a story and what isn't, and many Scrum teams don't do this effectively (What XP actually meant by "everything is a story" is that we plan around stories. We don't plan around all the other stuff that we have to do that isn't a story.)
      > >
      >
    • charles_bradley_scrum_coach
      Ron, ... Ok, then my opinion on that theme is: 1. I believe the technique you describe is an estimation technique, and I don t think I ll change my mind on
      Message 48 of 48 , Oct 9, 2010
      • 0 Attachment
        Ron,

        > > Do I have that much right?
        >
        > Yes ...

        Ok, then my opinion on that theme is:
        1. I believe the technique you describe is an estimation technique, and I don't think I'll change my mind on that. The minute you extrapolate your (historical)measurement in an effort to set customer/deadline expectations in the future, that's an estimate, IMO.

        Here is a definition of estimate I found at reference.com:
        <snip>
        1.to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately...
        </snip>

        I also believe that when someone decides that a story is "small" or even "too big to fit within a sprint", that is an estimate as well.

        2. What sent me 'round the bend was this comment from Steve:
        > .I think that's why I'm starting to join the "don't estimate them" crowd.
        What I took that to mean was that stories are never estimated in any way, to which I replied I don't know any org that can do well without *some sort* of estimation process to set customer expectations. Steve might have meant "don't estimate them[Using planning poker and story points]". That's the reason I attempted to clarify, although my attempt at clarification might have been not so good.

        I wrote:
        > I don't know how any organization can execute well without some sort of estimation process in order to set customer/stakeholder expectations appropriately.

        When I used the term "estimation process" here, I was not speaking of story pointing or any other specific estimation technique, just that *some sort or type* of estimation technique is needed.

        3. I see your technique as another estimation technique. To me, this is the real beauty of Scrum as a framework. The Scrum Guide says that backlog items are estimated, but it doesn't specify a particular technique for doing so. Your technique, IMO, is an estimation technique that was probably grown from the three pillars of Scrum theory: transparency, inspection, and adaptation. In my mind, it is just another candidate in the pool of other techniques that we discussed.

        4. Though I've never used your technique(caveat), I think I could see some situations where it would work really well and some situations where it might not work so well. You've described some actual observed evidence of where it worked well and why. I respect that. The technique is highly attractive in my mind, especially for certain situations. Like all techniques, I'm sure it has its advantages and disadvantages in different contexts/situations. Thanks for throwing another handy tool in my toolbox.

        I'll leave it at that for now. Thanks again for the excellent interchange of ideas.

        Charles
      Your message has been successfully submitted and would be delivered to recipients shortly.