Loading ...
Sorry, an error occurred while loading the content.
Skip to search.

Re: [scrumdevelopment] User Stories Opinion

Expand Messages
  • Jayanthan Bhattathiripad
    Something weird going on; but this was in reply to pirigyim@gmail.com.
    Message 1 of 48 , Sep 24, 2010
      Something weird going on; but this was in reply to pirigyim@....

      On Fri, Sep 24, 2010 at 2:05 PM, Mark Levison <mark@...> wrote:

      Jayanthan - an interesting email - but I'm not sure you sent it to the right place.

      Mark Levison

      On Fri, Sep 24, 2010 at 1:44 PM, Jayanthan Bhattathiripad <jynthn@...> wrote:


      Some things you might want to keep in mind and you can decide after speaking with your developers:

      - There might not be much of a value in splitting a story by field. Perhaps from a story size perspective A CMS user can add an article might be the same effort as A CMS user can add some fields in an article. If there is value in splitting it, then perhaps the way to split is to choose the more important fields first and then move to the less important ones? Required first?

      - I have to be honest and say that I haven't used a card in a while, more because of the geography of the teams and the relentless push of tool vendors (kidding). But if its important to write this down then I might have the fields defined as "Description MAX(100)". Perhaps a criteria that says "Verify commas can be used to delimit". For images "Verify max 640 X 400, 2mb". "Verify article date defaults to today". I am a big fan of criteria of this sort.

      - I would do Publish first before Schedule for Publish assuming that Schedule for Publish is an extension of Publish, with just the ability to specify when in the future it needs to be published

      - Curious: Does the Edit Article have two additional fields because of Update Date and Time?

      In the end, its all about communication, so your story can be what you like it to be as long as the developers know what needs to be done. Feedback from them and the Business Owners will help you evolve the format into something that works for this team. And if you haven't read User Stories Applied, Mike Cohn, I am sure you will find it as useful as I did when I first transitioned to writing stories.

      All the best,

    • 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

        > > 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:
        1.to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately...

        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.

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