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

Re: [scrumdevelopment] Re: Request for reference/reading material - Developer Stories

Expand Messages
  • Charles Bradley - Professional Scrum Trai
    +1 to Bill s post. Michael, I have an old post that somewhat covers this.  See Trap #2 in my User Story Traps article here: 
    Message 1 of 107 , Feb 25, 2013
      +1 to Bill's post.

      Michael,

      I have an old post that somewhat covers this.  See Trap #2 in my "User Story Traps" article here:  http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/
      (It's not my greatest post ever, but I still stand behind the concepts)

      For what the team was *trying* to achieve, this is the strategy I prefer:
      "The Dev Team Improvement Backlog"
      http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Backlog

      > "As a developer, I want to remove technical debt and improve test coverage before moving on to the next milestone."

      It's hard to tell from the context you gave whether the dev team had not met it's DoD in the past, or if it was trying improve the level of their current DoD.  In all honesty, having a dev team *admit*(transparency, courage, openness, commitment) that they want to do better technically is a good thing. 

      Was the story created to fix a failure to meet DoD in the past, or an attempt to improve upon the current DoD?
      Is their DoD well documented somewhere? 
      Are things like test coverage already documented in the DoD?

      -------
      Charles Bradley
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Saturday, February 23, 2013 3:57 AM
      Subject: Re: [scrumdevelopment] Re: Request for reference/reading material - Developer Stories



      Right Bill! +1 and all that …

      On Feb 22, 2013, at 10:11 PM, Bill Wake <bill@...> wrote:

      I've emphasized the weakness of stories about developers (not users) rather than the issue of "paying twice" to get the refactoring done, but maybe my blog article may help: '"As a Developer" is Not a User Story' - http://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/

      Here's an article with the same point from my site: Technical Stories - We don't need 'em.
      Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell





    • A Narasimhan
      Thanks a lot, George. Rgds-AN From: George Dinwiddie Sent: Saturday, April 20, 2013 8:55 PM To: scrumdevelopment@yahoogroups.com Subject: Re:
      Message 107 of 107 , Apr 21, 2013
        Thanks a lot, George.
        Rgds-AN
         
        Sent: Saturday, April 20, 2013 8:55 PM
        Subject: Re: [scrumdevelopment] CONCERN: over continuing Schisming/Fragmentation of Scrum & Agile
         
         

        AN,

        On 4/20/13 10:16 AM, A Narasimhan wrote:
        >
        >
        > Hi:
        > Recently there was a mail on Agile Scaling by Ron Jeffries which went
        > something
        > like this:
        > ‘Collaboration works in a team but not so much in a building...’ etc.
        > There were several points covered in that mail on scaling. I somehow
        > deleted that mail.
        > Can someone re-send the mail please...You could also send it to my
        > personal mail
        > mailto:an.narasimhan%40yahoo.co.in <mailto:mailto:an.narasimhan%40yahoo.co.in>
        > Rgds-AN

        Every email has a trailer that includes:

        > Visit Your Group
        > <http://groups.yahoo.com/group/scrumdevelopment

        You can go there to search for messages.

        - George

        --
        ----------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------

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