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

Scrum / Agile Guidelines and Checklist

Expand Messages
  • Michael Wollin
    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
    Message 1 of 20 , Apr 30, 2008
    • 0 Attachment
      Scrum / Agile Guidelines and Checklist 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".



    • Don Gray
      Michael, ... 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
      Message 2 of 20 , Apr 30, 2008
      • 0 Attachment
        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
      • banshee858
        ... This looks like a charter to me. I think it is a good step in the right direction for people starting with Scrum and holding them accountable. Carlton
        Message 3 of 20 , Apr 30, 2008
        • 0 Attachment
          >
          > 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.
          >
          This looks like a charter to me. I think it is a good step in the
          right direction for people starting with Scrum and holding them
          accountable.

          Carlton
        • Michael Wollin
          Don, The Product Owner role is through a couple of different proxies within our group. Think of them as Product Managers. We needed to clarify what we want
          Message 4 of 20 , Apr 30, 2008
          • 0 Attachment
            Re: [scrumdevelopment] Scrum / Agile Guidelines and Checklist Don,

            The Product Owner role is through a couple of different proxies within our group. Think of them as Product Managers. We needed to clarify what we want from them because we’ve been getting vague descriptions sometimes as they would relay what they heard in the field. That said, there is a lot of language in there to allow for “the conversation.” In this way, we are giving more power, on balance, to the development team.

            Michael


            On 4/30/08 5:43 PM, "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."
             

          • Michael Wollin
            Thank you. That was the idea. Transforming an organization that is of any size in which one is not the boss requires patience and occasionally a little more
            Message 5 of 20 , Apr 30, 2008
            • 0 Attachment
              Re: [scrumdevelopment] Re: Scrum / Agile Guidelines and Checklist Thank you. That was the idea. Transforming an organization that is of any size in which one is not the boss requires patience and occasionally a little more codification. People need to know what’s expected.


              On 4/30/08 5:55 PM, "banshee858" <cnett858@...> 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.
              >
              This looks like a charter to me.  I think it is a good step in the
              right direction for people starting with Scrum and holding them
              accountable.

              Carlton

            • Ilja Preuss
              ... If I were in your position, I would go further than just *allow* for a conversation. I would actively *seek* the conversation. And I would probably want to
              Message 6 of 20 , Apr 30, 2008
              • 0 Attachment
                Michael Wollin wrote:

                > The Product Owner role is through a couple of different proxies within
                > our group. Think of them as Product Managers. We needed to clarify what
                > we want from them because we’ve been getting vague descriptions
                > sometimes as they would relay what they heard in the field. That said,
                > there is a lot of language in there to allow for “the conversation.”

                If I were in your position, I would go further than just *allow* for a
                conversation. I would actively *seek* the conversation. And I would
                probably want to do that by shredding this document (the important parts
                should be in your brain by now, anyway), get everyone in one room, and
                start the conversation.

                I'm wondering - why isn't this conversation happening in your
                retrospectives already?

                Curious, Ilja
              • Don Gray
                Michael, ... Yes and no. Yes, I violently agree with the patience. When things change people s competence changes (for a short while this could be less
                Message 7 of 20 , Apr 30, 2008
                • 0 Attachment
                  Michael,

                  > Transforming an organization that is of any size in which one is not
                  > the boss requires patience and occasionally a little more
                  > codification.

                  Yes and no.

                  Yes, I violently agree with the patience. When things change people's
                  competence changes (for a short while this could be less competent.)
                  This affects their confidence and their comfort.

                  No, I don't believe organizations transform. People transform. When
                  enough people transform, the organization follows.

                  No, my experience doesn't support codification. This establishes
                  limits and quid pro quo. I do this then you do that (or vice-versa)
                  doesn't beget cross functional teamwork.

                  Given your circumstances I could be wrong, but agile codification
                  doesn't work for me. YMMV.

                  --
                  Don (336)374-7591

                  Nothing is more dangerous than an idea, when it's the only one you have.
                  Emile-Auguste Chartier
                  Pick up some new ideas at the AYE Conference Nov 2 - 5, 2008
                  www.AYEconference.com
                • George Dinwiddie
                  ... It /does/ sound like you intend to communicate through writing rather than conversation. I ve never found such an approach to produce better defined
                  Message 8 of 20 , Apr 30, 2008
                  • 0 Attachment
                    Michael Wollin 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:

                    It /does/ sound like you intend to communicate through writing rather
                    than conversation. I've never found such an approach to produce better
                    defined requirements. I think questions and answers work quite well.

                    This article
                    (http://xprogramming.com/xpmag/expCardConversationConfirmation.htm)
                    speaks of XP, but I think it's equally applicable to Scrum.

                    - George

                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * http://blog.gdinwiddie.com
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • MacKilby
                    I agree with some of the others: - patience is key - organization change happens one person at a time (sometimes one habit at a time also)... but it can happen
                    Message 9 of 20 , Apr 30, 2008
                    • 0 Attachment
                      I agree with some of the others:

                      - patience is key
                      - organization change happens one person at a time (sometimes one
                      habit at a time also)... but it can happen in parallel with the right
                      facilitation
                      - conversation over codification (just like people over process...
                      both are important, but one is more important)

                      That being said, I have no problem if this document is a charter for
                      an individual team. Some teams I've found do need this codification
                      at the start, but it ends up becoming a disposable document as trust
                      builds on the team (and I'm thinking PO, SM, and developers when I say
                      team).

                      Mark Kilby

                      --- In scrumdevelopment@yahoogroups.com, Don Gray <don@...> wrote:
                      >
                      > Michael,
                      >
                      > > Transforming an organization that is of any size in which one is not
                      > > the boss requires patience and occasionally a little more
                      > > codification.
                      >
                      > Yes and no.
                      >
                      > Yes, I violently agree with the patience. When things change people's
                      > competence changes (for a short while this could be less competent.)
                      > This affects their confidence and their comfort.
                      >
                      > No, I don't believe organizations transform. People transform. When
                      > enough people transform, the organization follows.
                      >
                      > No, my experience doesn't support codification. This establishes
                      > limits and quid pro quo. I do this then you do that (or vice-versa)
                      > doesn't beget cross functional teamwork.
                      >
                      > Given your circumstances I could be wrong, but agile codification
                      > doesn't work for me. YMMV.
                      >
                      > --
                      > Don (336)374-7591
                      >
                      > Nothing is more dangerous than an idea, when it's the only one you have.
                      > Emile-Auguste Chartier
                      > Pick up some new ideas at the AYE Conference Nov 2 - 5, 2008
                      > www.AYEconference.com
                      >
                    • Ilja Preuss
                      ... I agree, when the document states what the team members expect from each other, and when all the team members agree that it is the right thing to do, and
                      Message 10 of 20 , May 1, 2008
                      • 0 Attachment
                        MacKilby wrote:

                        > That being said, I have no problem if this document is a charter for
                        > an individual team. Some teams I've found do need this codification
                        > at the start, but it ends up becoming a disposable document as trust
                        > builds on the team (and I'm thinking PO, SM, and developers when I say
                        > team).

                        I agree, when the document states what the team members expect from each
                        other, and when all the team members agree that it is the right thing to
                        do, and agree on the content of the document. That is, when the document
                        is the *result* of a conversation between all the affected people.

                        That's not what I understood Michael's situation to be. It sounded to me
                        as if the document codified what the team expected from "outside"
                        members, and as if those possibly even hadn't been asked whether they
                        wanted such a documented, and as if the document came *before* the
                        conversation with all those affected. To the amount that this impression
                        is correct, it would trouble me.

                        Cheers, Ilja
                      • banshee858
                        ... We don t know that. This could be the first draft or a starting point for the discussion. A lot of people do not understand what Scrum is or how it works
                        Message 11 of 20 , May 1, 2008
                        • 0 Attachment
                          >
                          > I agree, when the document states what the team members expect from
                          > each other, and when all the team members agree that it is the right
                          > thing to do, and agree on the content of the document. That is, when
                          > the document is the *result* of a conversation between all the
                          > affected people.
                          >
                          > That's not what I understood Michael's situation to be. It sounded to
                          > me as if the document codified what the team expected from "outside"
                          > members, and as if those possibly even hadn't been asked whether they
                          > wanted such a documented, and as if the document came *before* the
                          > conversation with all those affected. To the amount that this
                          > impression is correct, it would trouble me.
                          >
                          We don't know that. This could be the first draft or a starting point
                          for the discussion. A lot of people do not understand what Scrum is
                          or how it works day-to-day, describing that makes things clear.

                          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.

                          Carlton
                        • Michael Wollin
                          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
                          Message 12 of 20 , May 1, 2008
                          • 0 Attachment
                            Re: [scrumdevelopment] Re: Scrum / Agile Guidelines and Checklist 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. Among its purposes, it tries to reassure the developers that they are not being asked to estimate or commit to implementing poorly defined stories.

                            The document is a response to continued confusion on the team’s part (PO, SM, developers, and QA – i.e., everybody). Each individual member seems to take away something different. Sometimes you just have to write it down in order to get everyone to “hear green when you say green.”

                            Ultimately, it’s all about building trust. Scrum explicitly intends to give the team a great deal of empowerment and control. It values team morale, job satisfaction and fun. We are not there. We are not near there. But we did not start from scratch, and Rome wasn’t built in a day.


                            On 5/1/08 3:34 AM, "Ilja Preuss" <it@...> wrote:

                            MacKilby wrote:

                            > That being said, I have no problem if this document is a charter for
                            > an individual team.  Some teams I've found do need this codification
                            > at the start, but it ends up becoming a disposable document as trust
                            > builds on the team (and I'm thinking PO, SM, and developers when I say
                            > team).

                            I agree, when the document states what the team members expect from each
                            other, and when all the team members agree that it is the right thing to
                            do, and agree on the content of the document. That is, when the document
                            is the *result* of a conversation between all the affected people.

                            That's not what I understood Michael's situation to be. It sounded to me
                            as if the document codified what the team expected from "outside"
                            members, and as if those possibly even hadn't been asked whether they
                            wanted such a documented, and as if the document came *before* the
                            conversation with all those affected. To the amount that this impression
                            is correct, it would trouble me.

                            Cheers, Ilja
                          • Ilja Preuss
                            ... Correct. That s what I tried to express. ... In my experience, a document is seldom a good starting point for a discussion. And if it is supposed to be, it
                            Message 13 of 20 , May 1, 2008
                            • 0 Attachment
                              banshee858 wrote:
                              >> I agree, when the document states what the team members expect from
                              >> each other, and when all the team members agree that it is the right
                              >> thing to do, and agree on the content of the document. That is, when
                              >> the document is the *result* of a conversation between all the
                              >> affected people.
                              >>
                              >> That's not what I understood Michael's situation to be. It sounded to
                              >> me as if the document codified what the team expected from "outside"
                              >> members, and as if those possibly even hadn't been asked whether they
                              >> wanted such a documented, and as if the document came *before* the
                              >> conversation with all those affected. To the amount that this
                              >> impression is correct, it would trouble me.
                              >>
                              > We don't know that.

                              Correct. That's what I tried to express.

                              > This could be the first draft or a starting point
                              > for the discussion.

                              In my experience, a document is seldom a good starting point for a
                              discussion. And if it is supposed to be, it doesn't make much sense to
                              get it *right*, anyway - in that case, we are simply the wrong people to
                              get input from.

                              > A lot of people do not understand what Scrum is
                              > or how it works day-to-day, describing that makes things clear.

                              And one of the base tenets of Agile - and therefore I guess also Scrum -
                              is that face-to-face conversation is ways more effective than written
                              communication. If we believe that to be true, we probably should act
                              that way, too, shouldn't we?

                              > 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 like that analogy! :)

                              Cheers, Ilja
                            • David H.
                              e? ... I thought User Stories remind us to have a conversation and as such they are always still a little ambiguous...? -d -- Sent from gmail so do not trust
                              Message 14 of 20 , May 1, 2008
                              • 0 Attachment
                                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...?

                                -d
                                --
                                Sent from gmail so do not trust this communication.
                                Do not send me sensitive information here, ask for my none-gmail accounts.

                                "Therefore the considerations of the intelligent always include both
                                benefit and harm." - Sun Tzu
                              • Tobias Mayer
                                A little off-track perhaps, but this thread reminds me of an organization that I worked with about eighteen months ago. The team members there created a
                                Message 15 of 20 , May 1, 2008
                                • 0 Attachment
                                  A little off-track perhaps, but this thread reminds me of an organization that I worked with about eighteen months ago.  The team members there created a charter for themselves, to indicate their sense of responsibility to the organization and the Scrum process.  This is it:

                                  Framework: We commit to following Agile principles to the best of our ability using the whole Scrum framework.
                                  Quality: We commit to building quality into our products at every stage of their development and to continuously review and improve our techniques for achieving this.
                                  People: We are professionals and have a responsibility to respect each other, act honestly, communicate openly and assist/seek assistance where appropriate.
                                  Process: We commit to working with the organization to define a minimal process to guide our activities over the duration of each sprint, empowering teams to get the job done.
                                  Growth: As individuals, we commit to enhancing and furthering our knowledge and to share that knowledge, as appropriate, with others at [this_company].

                                  I like the simplicity of this, and the fact it was generated by three teams, collaboratively. I also like that it is non-prescriptive and focuses on values rather than detailed tasks and activities.  The blog post I wrote about how this charter emerged is here:  Spiderman Says...

                                  A document like this is certainly a starting point for conversation.  I am not sure that the document Michael Wollin proposed will have that effect, mainly because I am not convinced people will even read it. 

                                  Tobias



                                  --- In scrumdevelopment@yahoogroups.com, Ilja Preuss <it@...> wrote:
                                  >
                                  > banshee858 wrote:
                                  > >> I agree, when the document states what the team members expect from
                                  > >> each other, and when all the team members agree that it is the right
                                  > >> thing to do, and agree on the content of the document. That is, when
                                  > >> the document is the *result* of a conversation between all the
                                  > >> affected people.
                                  > >>
                                  > >> That's not what I understood Michael's situation to be. It sounded to
                                  > >> me as if the document codified what the team expected from "outside"
                                  > >> members, and as if those possibly even hadn't been asked whether they
                                  > >> wanted such a documented, and as if the document came *before* the
                                  > >> conversation with all those affected. To the amount that this
                                  > >> impression is correct, it would trouble me.
                                  > >>
                                  > > We don't know that.
                                  >
                                  > Correct. That's what I tried to express.
                                  >
                                  > > This could be the first draft or a starting point
                                  > > for the discussion.
                                  >
                                  > In my experience, a document is seldom a good starting point for a
                                  > discussion. And if it is supposed to be, it doesn't make much sense to
                                  > get it *right*, anyway - in that case, we are simply the wrong people to
                                  > get input from.
                                  >
                                  > > A lot of people do not understand what Scrum is
                                  > > or how it works day-to-day, describing that makes things clear.
                                  >
                                  > And one of the base tenets of Agile - and therefore I guess also Scrum -
                                  > is that face-to-face conversation is ways more effective than written
                                  > communication. If we believe that to be true, we probably should act
                                  > that way, too, shouldn't we?
                                  >
                                  > > 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 like that analogy! :)
                                  >
                                  > Cheers, Ilja
                                  >
                                • Ilja Preuss
                                  ... 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
                                  Message 16 of 20 , May 1, 2008
                                  • 0 Attachment
                                    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
                                  • 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 17 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 18 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 19 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 20 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.