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

Re: [scrumdevelopment] Re: Scrum / Agile Guidelines and Checklist

Expand Messages
  • Ilja Preuss
    ... I think that s what Carlton tried to say: the story (card) doesn t *contain* the details, it is just a token to help us remember the details that we got
    Message 1 of 20 , May 1, 2008
    • 0 Attachment
      David H. wrote:
      > e?
      >> > FWIW, it is a little detailed for my taste and could be boiled down to
      >> > a few key principles that remind us of the details. Much like a user
      >> > story reminds us of the details of the requirements.
      >>
      > I thought User Stories remind us to have a conversation and as such
      > they are always still a little ambiguous...?

      I think that's what Carlton tried to say: the story (card) doesn't
      *contain* the details, it is just a token to help us remember the
      details that we got from somewhere else (discussions, acceptance tests,
      etc.)

      Cheers, Ilja
    • Michael Wollin
      Sure does help. Feel free to suggest more.
      Message 2 of 20 , May 1, 2008
      • 0 Attachment
        Sure does help. Feel free to suggest more.


        On 5/1/08 5:00 PM, "Ilja Preuss" <it@...> wrote:

        > Michael Wollin wrote:
        >> This document is for ³inside,² if you include PO¹s who are really
        >> internal proxies for the actual customers. It is a continuation of an
        >> ongoing conversation and a strawman draft offered up for comment by the
        >> development team.
        >
        > OK, perhaps I misunderstood some of your previous statements. To the
        > amount that this document just captures the results of your discussions
        > in the Whole Team, that sounds good to me, in principle.
        >
        > In the rest of this post, I will comment on the form of the document,
        > and ignore the content for now.
        >
        > I would probably try to get it a bit shorter, to boil it down to a list
        > of essential working agreements. When it gets too long (say, more than
        > seven bullet points that apply to my working), I'm not able to keep them
        > in my head.
        >
        > I prefer working agreements stated in a way as if I'm already doing
        > those things. The first of your points is already close:
        >
        > "We will use the Wiki to capture stories, and details in the story."
        >
        > Just remove the "will": "We use the Wiki to capture stories, and details
        > in the story."
        >
        > Taking another example:
        >
        > "The minimum basic details must be entered into a user story at least 24
        > hours prior to the sprint planning meeting by the product owner. If
        > not, there is no requirement for the team to assess the story (they can
        > if they want to, but do not have to)."
        >
        > I would reformulate that again to fit the above pattern:
        >
        > "The product owner enters the minimum basic details into a user story at
        > least 24 hours prior to the sprint planning meeting."
        >
        > I'm uncomfortable with that second sentence, for a number of reasons. It
        > has a strong defensive, threatening and divisive feel to me, and
        > destroys the energizing effect the first statement could have. Therefore
        > I would just scrap it.
        >
        > I hope you this helps.
        >
        > Cheers, Ilja
        >
        > ------------------------------------
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...! Groups Links
        >
        >
        >
      • aalanatlas
        +1 cringe.
        Message 3 of 20 , May 2, 2008
        • 0 Attachment
          +1 cringe.

          --- In scrumdevelopment@yahoogroups.com, Don Gray <don@...> wrote:
          >
          > Michael,
          >
          > > This is an excerpt of a document that we want to use to clarify
          > > what’s expected from all concerned in our group. I would appreciate
          > > some feedback.
          >
          > I cringed.
          >
          > I wondered what happened to "Customer collaboration over contract
          > negotiation".
          >
          > I didn't get a sense of "let's figure out how to make this work."
          >
          > --
          > Don (336)374-7591
          >
          > He who knows others is clever;
          > He who knows himself is enlightened.
          > Lao-Tzu
          >
          > Learn about yourself at the AYE Conference, Nov 2 - 5, 2008.
          > www.AYEconference.com
          >
        • the_1wkndr
          Hi Mike, I ve used a format that seems to work well for us in terms of clearly identifying the event/time box (Sprint Planning 1)...then outlining very simply
          Message 4 of 20 , May 5, 2008
          • 0 Attachment
            Hi Mike,

            I've used a format that seems to work well for us in terms of clearly
            identifying the event/time box (Sprint Planning 1)...then outlining
            very simply who should attend (Team, Product Owner) and a bullet list
            of what the inputs, actions and outputs should be. When I wrote the
            training for our teams...I used this style to help them quickly grasp
            the concept w/o getting to mired in a lot of details. To agree with
            another poster...its the people that transform and the easier it is
            for them to put into practice a new concept...the less patience you'll
            need with the transformation! They'll get it!

            I'm teaching a new team now how to use this outline to work with folks
            in our organization who aren't quite fully Scrum trained. I tell them
            if they know what the need and how to get it (ie. actions and outputs
            from whatever event) they can speak intelligibly to the meeting guest
            (might be an untrained product owner)...about what they need and how
            they want to see it.

            If you'd like a sample of the template, I'm happy to share.

            Alicia McLain
            San Diego, CA
            http://www.scrumalliance.org/profiles/8895-alicia-r-mclain
            http://www.linkedin.com/in/aliciamclain

            --- In scrumdevelopment@yahoogroups.com, Michael Wollin <yahoo@...> wrote:
            >
            > This is an excerpt of a document that we want to use to clarify what¹s
            > expected from all concerned in our group. I would appreciate some
            feedback.
            >
            > The idea here is not to create some 'legal document' (even if it
            starting to
            > sound like one on re-reading it) - but instead to try and ensure we
            are all
            > on the same page about what everyone expects of each other.
            >
            > User Stories
            > * We will use the Wiki to capture stories, and details in the story.
            > * The product owner or BA will ensure that the following is entered into
            > each story on the WIKI:
            > > * Basic business acceptance criteria
            > > * Known assumptions (basic business assumptions)
            > > * Known requirements of the story
            > > * Known failure modes (if any are known by the product owner)
            >
            > Contract
            > * The minimum basic details must be entered into a user story at
            least 24
            > hours prior to the sprint planning meeting by the product owner. If
            not,
            > there is no requirement for the team to assess the story (they can
            if they
            > want to, but do not have to).
            > * If the story has basic details (outlined in "stories" above) then an
            > attempt will be made to assess it. If the details are too vague or
            unclear
            > then the team will ask the product owner for more information during the
            > sprint planning meeting.
            > * Ideally the basic details will be in the story prior to the story
            point
            > planning meeting - but this is NOT required.
            > * Once the story has been planned in the sprint planning and we have a
            > "commitment" to implement then the team will endeavor to complete the
            > implementation - including unit, system and integration testing (without
            > release QA) - within the sprint.
            > * A story is only completed when it has been unit tested, system
            tested and
            > integration tested. So it needs to be ready to go into a release
            candidate.
            > It is possible, and often likely, that it wouldn't make sense for it
            to be
            > in a release candidate yet - but it MUST be ready for one.
            > * The team's commitment to implement will include implementing all
            the tasks
            > defined, and any additional ones that the team find are necessary and
            > reasonable, based on their good-faith professional opinion, during
            > development. The commitment will also include addressing all
            failure modes
            > that were identified and included in the story.
            > * Any failure modes or new tasks (related to newly discovered edge
            cases,
            > etc) discovered during implementation but not listed during the planning
            > meeting, or excluded failure modes, will NOT be included in the
            commitment
            > to implement. This means that we will view the story AS COMPLETE if it
            > meets the acceptance criteria and identified failure modes EVEN IF
            it fails
            > on some newly discovered failure modes.
            > * The team may elect to address newly discovered failure modes or
            tasks if
            > they wish during sprint BUT it is essential that addressing these
            new tasks
            > does not impact the commitment to completing the other stories in the
            > sprint. This is completely the teams choice and NOT management or the
            > product owner. [For example, if the team chooses not to address the
            task,
            > and to put it on the backlog, the product owner does not have the
            right to
            > force them to work on it until the next sprint].
            > * Stories not completed go back into the backlog at the end of the
            sprint.
            > Of course stories should have been completed based on the commitment,
            > however external circumstances such as production support, illness,
            etc.,
            > may cause delays and when this happens the story must return to the
            backlog.
            >
            > Sprint Planning Meeting Guidelines
            > * During the sprint planning meetings we will look at the stories
            identified
            > for the current/next release.
            > * We will pick stories from the release, ideally in order or
            importance - if
            > that has been identified
            > * We will spend 20 (TWENTY) minutes on each story.
            > * For each story we will address everything in the checklist that
            follows.
            > * If we are not complete when the 20 minutes is up we will add a 30
            minute
            > analysis meeting task and move on to the next story.
            >
            > Sprint Planning Checklist
            > * Each individual will define how much time they have to commit to the
            > sprint. Individuals must take into account the following when then
            commit
            > their time:
            > > * There should be a reasonable amount of time set aside for
            production support
            > > issues.
            > > * Note that all non-critical defects should go on the backlog. If
            a defect
            > > requires immediate work then it is a critical defect and is
            covered under
            > > production support time.
            > * Look at a story and spend 10 minutes doing the following:
            > > * Review the assumptions
            > > * Review, clarify and expand on the acceptance criteria (*)
            > > * Review and clarify the requirements
            > > * Brainstorm the possible failure modes
            > > * What happens if we run out of time? [we ask the team if they
            want to
            > > continue, if not then we skip the story]
            > * Based on the acceptance criteria, requirements and failure modes,
            spend 10
            > minutes:
            > > * Defining tasks required to implement this story
            > > * Estimate how long each task will take in ideal hours
            > > * If we run out of time we add a task called "30 MINUTE ANALYSIS
            MEETING"
            > * Commitment: If we managed to identify all tasks and add ideal
            hours then
            > the team will say whether they are willing to commit to this story
            in this
            > sprint.
            >
            > How do we brainstorm the failure modes and what do we do with them?
            > * Everyone should state whatever they think might be an issue and it
            will be
            > captured.
            > * We must NOT argue about failure modes - if it is stated then it gets
            > written down
            > > * If we determine it isn't an issue at a later date (i.e., as we
            look at
            > > tasks) then that is fine
            > * We should use prior experience and general paranoia to drive us to
            define
            > acceptance criteria - i.e. assume everything that can go wrong will go
            > wrong.
            > * Some failure modes will NOT be made part of the story - we may
            make them
            > their own stories.
            >
            > Other Guidelines
            > The team should be careful about the wording of the acceptance criteria.
            > Overly generalized criteria should be avoided. Blanket coverage of
            failure
            > modes should be avoided in failure modes: for example, an acceptance
            > criteria should not end with "... and will work in all possible cases,
            > everywhere in the known universe".
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.