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

Re: [scrumdevelopment] Re: Planning Poker

Expand Messages
  • Henrik Kniberg
    What makes you think all the figures are male? Just because they are fat and short-haired? You better hope Mrs B and Mrs C don t see your comment... :o)
    Message 1 of 19 , Jun 6, 2007
    • 0 Attachment
      What makes you think all the figures are male? Just because they are fat and short-haired? You better hope Mrs B and Mrs C don't see your comment... :o)

      /Henrik

      On 5/31/07, Dave Nicolette <dnicolet@...> wrote:

      The graphical presentation is nice, but the little figures are all
      male. Why are there no women on the team? I thought Sweden was
      progressive! ;-)

      Dave



      --- In scrumdevelopment@yahoogroups.com, "Henrik Kniberg" <h@...> wrote:
      >
      > I meet a lot of people who've heard about Planning Poker but don't
      > really understand what it is or how it works.
      >
      > Here's an attempt to describe Planning Poker in a clear and
      graphical way:
      > http://www.crisp.se/planningpoker/
      >
      > /Henrik
      >
      > --
      > Henrik Kniberg
      > http://www.crisp.se
      > +46 (0)70 492 5284
      >




      --
      Henrik Kniberg
      http://www.crisp.se
      +46 (0)70 492 5284
    • Dave Nicolette
      Hmm...I could have sworn B and C were labeled Mr when I first read it. There a an old joke about two newborn babies in the hospital. One says to the other,
      Message 2 of 19 , Jun 6, 2007
      • 0 Attachment
        Hmm...I could have sworn B and C were labeled "Mr" when I first read it.

        There'a an old joke about two newborn babies in the hospital. One says
        to the other, "Are you a boy or a girl?" The second baby says, "I
        don't know. How can you tell?" "Easy!" says the first, throwing aside
        the blanket, "Blue booties for boys, pink for girls!"

        On reviewing the web page, I realized that one cannot see the shoes of
        the figures in the illustration. No doubt this was the cause of my
        confusion. I apologize for my error.

        Dave


        --- In scrumdevelopment@yahoogroups.com, "Henrik Kniberg" <h@...> wrote:
        >
        > What makes you think all the figures are male? Just because they are
        fat and
        > short-haired? You better hope Mrs B and Mrs C don't see your
        comment... :o)
        >
        > /Henrik
        >
        > On 5/31/07, Dave Nicolette <dnicolet@...> wrote:
        > >
        > > The graphical presentation is nice, but the little figures are all
        > > male. Why are there no women on the team? I thought Sweden was
        > > progressive! ;-)
        > >
        > > Dave
        > >
        > >
        > > --- In
        scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
        > > "Henrik Kniberg" <h@...> wrote:
        > > >
        > > > I meet a lot of people who've heard about Planning Poker but don't
        > > > really understand what it is or how it works.
        > > >
        > > > Here's an attempt to describe Planning Poker in a clear and
        > > graphical way:
        > > > http://www.crisp.se/planningpoker/
        > > >
        > > > /Henrik
        > > >
        > > > --
        > > > Henrik Kniberg
        > > > http://www.crisp.se
        > > > +46 (0)70 492 5284
        > > >
        > >
        > >
        > >
        >
        >
        >
        > --
        > Henrik Kniberg
        > http://www.crisp.se
        > +46 (0)70 492 5284
        >
      • Michael Vizdos
        Hola, The cartoon next week will examine this and I will have some great links using this thread! Thank you. - mike vizdos www.implementingscrum.com
        Message 3 of 19 , Jun 8, 2007
        • 0 Attachment
          Hola,

          The cartoon next week will examine this and I will have some great links using this thread!

          Thank you.

          - mike vizdos
            www.implementingscrum.com
            www.michaelvizdos.com


          On 5/30/07, Henrik Kniberg <h@...> wrote:

          I meet a lot of people who've heard about Planning Poker but don't
          really understand what it is or how it works.

          Here's an attempt to describe Planning Poker in a clear and graphical way:
          http://www.crisp.se/planningpoker/

          /Henrik

          --
          Henrik Kniberg
          http://www.crisp.se
          +46 (0)70 492 5284


        • Michael Vizdos
          As promised.... Adding to the already superb work on this topic: http://www.implementingscrum.com/cartoons/cartoons_files/implementingscrum-20070611.html -
          Message 4 of 19 , Jun 11, 2007
          • 0 Attachment
            As promised.... Adding to the already superb work on this topic:

            http://www.implementingscrum.com/cartoons/cartoons_files/implementingscrum-20070611.html

            - mike vizdos
              www.implementingscrum.com
              www.michaelvizdos.com


            On 6/8/07, Michael Vizdos <mvizdos@...> wrote:
            Hola,

            The cartoon next week will examine this and I will have some great links using this thread!

            Thank you.

            - mike vizdos
              www.implementingscrum.com
              www.michaelvizdos.com



            On 5/30/07, Henrik Kniberg <h@...> wrote:

            I meet a lot of people who've heard about Planning Poker but don't
            really understand what it is or how it works.

            Here's an attempt to describe Planning Poker in a clear and graphical way:
            http://www.crisp.se/planningpoker/

            /Henrik

            --
            Henrik Kniberg
            http://www.crisp.se
            +46 (0)70 492 5284



          • Thushara Wijewardena
            We played Planning Poker for the 1st time and I had following concerns.Can you experienced SCUM guys help me ? Please apologize me if the questions sound bit
            Message 5 of 19 , Sep 18, 2008
            • 0 Attachment
              We played Planning Poker for the 1st time and I had following
              concerns.Can you experienced SCUM guys help me ? Please apologize me
              if the questions sound bit awkward, Im still trying to get in to the
              whole game..In my country there is no SCRUM training yet.

              1. When Moderator reads 1 story we kept playing Poker and came out of
              an estimation to that specific story., But when we went through the PB
              more and more., team wanted to revise the previous story estimates
              again as its a comparative thing., How do you handle this situation?
              Do you get the team to analyze the PB before coming to Planning poker
              so they will be more or less accurate with their comparative guess
              with other user stories in the rest of the product backlog?

              2.There was one user story which we had to purchase some device for
              that. Scrum master ask where do we do the procurement management,
              planning , Cost estimation etc, Will SCRUM has some guidelines for
              procurement management for the project.

              3. Customer who acted as the product owner didnt have answers for some
              of the questions.. there were situations such as I need to check with
              my infrastructure guys.. I need to ask my BI manager etc. How do you
              tackle that situation?

              4. for certain stories we felt that we need the use cases or further
              analysis before thinking of their weight. ..

              5. Looking at from the Project Office I saw many team for many
              projects they had different type of assessments. As an Example., same
              story "User needs to log in to the site and fill the registration
              form" was rated by the Team A as 5 and Team B as 20.. so how do I
              compare and see each team performance from the top when I look at my
              teams product burn down charts?


              Thanks a lot for your help

              Thush
            • chuckspublicprofile
              Hello Thush... See my comments inline. This is just my humble advice. ... Don t panic, this is a pretty common challenge. I can think of two ways around it.
              Message 6 of 19 , Sep 18, 2008
              • 0 Attachment
                Hello Thush... See my comments inline. This is just my humble advice.

                --- In scrumdevelopment@yahoogroups.com, "Thushara Wijewardena"
                <thush.ksnz@...> wrote:
                >
                > We played Planning Poker for the 1st time and I had following
                > concerns.Can you experienced SCUM guys help me ? Please apologize me
                > if the questions sound bit awkward, Im still trying to get in to the
                > whole game..In my country there is no SCRUM training yet.
                >
                > 1. When Moderator reads 1 story we kept playing Poker and came out of
                > an estimation to that specific story., But when we went through the PB
                > more and more., team wanted to revise the previous story estimates
                > again as its a comparative thing., How do you handle this situation?
                > Do you get the team to analyze the PB before coming to Planning poker
                > so they will be more or less accurate with their comparative guess
                > with other user stories in the rest of the product backlog?

                Don't panic, this is a pretty common challenge. I can think of two
                ways around it.

                First, when the PB is established, assuming it has lots of items of
                varying sizes, maybe you could do something like take 2 Planning Poker
                passes through the estimates, and allow folks to adjust. Also, my
                personal strategy is that any point estimate is later revisable by the
                team so long as you are STILL in the planning meeting. After that, no
                changes until the next planning meeting.

                Another potential solution is to do what we did. We tried to imagine
                the sizes of things we might potentially tackle. Our system has been
                in production for quite some time, so we do bug fixes and
                enhancements. We take on tasks of the following nature:

                1. Quick (legacy) bug fixes, taking 1-4 ideal hours.
                2. Difficult (legacy) bug fixes, taking 2-12 ideal hours.
                3. Easy enhancements, taking from 10-30 ideal hours.
                4. New features, taking from ~5-?? ideal hours.
                5. Complex enchancements, taking from 20-?? ideal hours.

                First of all, we make a point NOT to equate ideal hours and points,
                we're just getting a feel for the range of our work. They are
                related, but only roughly so. We first made sure that we would leave
                some of the extreme numbers out, to give us some wiggle room (numbers
                like 0, 1/2, 1, 80, 100, etc). Then, we decided to estimate the
                largest story that safely could be done in a 2 week sprint. We
                figured that would be about 40 ideal hours(6 ideal hrs/day * 10 days =
                60 ideal hours per sprint), and we decided to assign that 20 points.
                Some sources recommend doing no Stories that will take more than half
                a sprint. Anything over 20 had to be split, so anything over 20 would
                essentially be a ? or infinity until it was broken down. So, we're
                left with numbers 2,3,5,8,13,20,?. From that point on, it was pretty
                easy for us to spread point estimates between a 2 point story that
                takes a few ideal hours to a 20 point story that would take just less
                than 2 weeks. We also try to leave the whole concept of "ideal hours"
                behind when utilizing points. We also sometimes think in terms of "An
                8 should take roughly *roughly* as long as a 2". We found that the
                sizes of our bug fixes were so variable that we added in 0, 1/2, and 1
                to our point scale.

                Be careful if you decide to significantly modify your Story Point
                scale at a later time. If you do, then if you're tracking velocity at
                all, you'll need to go back and adjust the old velocities/story points
                too. Others may have feedback here.

                >
                > 3. Customer who acted as the product owner didnt have answers for some
                > of the questions.. there were situations such as I need to check with
                > my infrastructure guys.. I need to ask my BI manager etc. How do you
                > tackle that situation?

                We do "Pre-Planning" meetings with the PO and other stakeholders
                before the actual Sprint Planning Meeting on Day one of the sprint.
                We usually have an initial "Pre-Planning" meeting 3 days before the
                next sprint, then a follow up meeting 2 days before the next sprint.
                This way the PO has 2 meetings to resolve questions, the team has 2
                meetings to raise questions and begin thinking of estimates, and then
                any remaining details can be handled outside of the meetings so that
                the PO and the team are ready at the Sprint Planning meeting. We find
                this *highly useful*.

                >
                > 4. for certain stories we felt that we need the use cases or further
                > analysis before thinking of their weight. ..

                "Pre-planning" meetings and having any reqs docs finalized BEFORE said
                "Pre-Planning" meetings would probably be useful here.

                >
                > 5. Looking at from the Project Office I saw many team for many
                > projects they had different type of assessments. As an Example., same
                > story "User needs to log in to the site and fill the registration
                > form" was rated by the Team A as 5 and Team B as 20.. so how do I
                > compare and see each team performance from the top when I look at my
                > teams product burn down charts?
                >

                I think others will have better feedback here than I, and this is just
                MHO, but I would NOT recommend using points as a way to judge
                performance OF ANY KIND IN ANY WAY, SHAPE, OR FORM. I think you would
                use some other non-scrum related tools/techniques for that. One
                problem with that is the problem you mentioned, that teams should set
                their own story point estimate strategy, and the strategy need not be
                the same or similar from team to team.

                >
                > Thanks a lot for your help
                >
                > Thush
                >
              • chuckspublicprofile
                Henrik, I like what you ve done there. It really helps communicate some of the real problems with doing things the old way. I don t know who your target
                Message 7 of 19 , Sep 18, 2008
                • 0 Attachment
                  Henrik,

                  I like what you've done there. It really helps communicate some of
                  the real problems with doing things the "old way."

                  I don't know who your target audience is, really, but I would
                  recommend some text between your hours example and points example to
                  describe a little more how of folks would transition from using hours
                  to points. Maybe something like "Points represent relative sizes, so
                  an 8 point story is very roughly four times the size of a 2 point
                  story" or "Points give you a rough idea of how much work can be done
                  in an iteration, so an 8 point story is bigger than a 5 point story is
                  bigger than a 2 point story, and so on." Anyway, something like that.

                  Charles



                  --- In scrumdevelopment@yahoogroups.com, "Henrik Kniberg" <h@...> wrote:
                  >
                  > I meet a lot of people who've heard about Planning Poker but don't
                  > really understand what it is or how it works.
                  >
                  > Here's an attempt to describe Planning Poker in a clear and
                  graphical way:
                  > http://www.crisp.se/planningpoker/
                  >
                  > /Henrik
                  >
                  > --
                  > Henrik Kniberg
                  > http://www.crisp.se
                  > +46 (0)70 492 5284
                  >
                • Kai Schl├╝ter
                  Well, even more funny was when i heard my daughter discussing with her friend from the neighborhood how they would know that a not born baby is male or female:
                  Message 8 of 19 , Sep 19, 2008
                  • 0 Attachment
                    Well,
                    even more funny was when i heard my daughter discussing with her
                    friend from the neighborhood how they would know that a not born baby
                    is male or female:

                    "If it is a girl it has long hair...."

                    Wisdom of 4 year olds.

                    Regards,
                    Kai

                    --- In scrumdevelopment@yahoogroups.com, "Dave Nicolette"
                    <dnicolet@...> wrote:
                    >
                    > Hmm...I could have sworn B and C were labeled "Mr" when I first read
                    it.
                    >
                    > There'a an old joke about two newborn babies in the hospital. One says
                    > to the other, "Are you a boy or a girl?" The second baby says, "I
                    > don't know. How can you tell?" "Easy!" says the first, throwing aside
                    > the blanket, "Blue booties for boys, pink for girls!"
                    >
                    > On reviewing the web page, I realized that one cannot see the shoes of
                    > the figures in the illustration. No doubt this was the cause of my
                    > confusion. I apologize for my error.
                    >
                    > Dave
                    >
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Henrik Kniberg" <h@...> wrote:
                    > >
                    > > What makes you think all the figures are male? Just because they are
                    > fat and
                    > > short-haired? You better hope Mrs B and Mrs C don't see your
                    > comment... :o)
                    > >
                    > > /Henrik
                    > >
                    > > On 5/31/07, Dave Nicolette <dnicolet@> wrote:
                    > > >
                    > > > The graphical presentation is nice, but the little figures are all
                    > > > male. Why are there no women on the team? I thought Sweden was
                    > > > progressive! ;-)
                    > > >
                    > > > Dave
                    > > >
                    > > >
                    > > > --- In
                    > scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
                    > > > "Henrik Kniberg" <h@...> wrote:
                    > > > >
                    > > > > I meet a lot of people who've heard about Planning Poker but don't
                    > > > > really understand what it is or how it works.
                    > > > >
                    > > > > Here's an attempt to describe Planning Poker in a clear and
                    > > > graphical way:
                    > > > > http://www.crisp.se/planningpoker/
                    > > > >
                    > > > > /Henrik
                    > > > >
                    > > > > --
                    > > > > Henrik Kniberg
                    > > > > http://www.crisp.se
                    > > > > +46 (0)70 492 5284
                    > > > >
                    > > >
                    > > >
                    > > >
                    > >
                    > >
                    > >
                    > > --
                    > > Henrik Kniberg
                    > > http://www.crisp.se
                    > > +46 (0)70 492 5284
                    > >
                    >
                  • sdedwards53
                    ... Here are my two-cents to your numbered questions (you get what you paid for): 1. I think its fine if the team wants to revisit a previously-estimated
                    Message 9 of 19 , Sep 19, 2008
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, "Thushara Wijewardena"
                      <thush.ksnz@...> wrote:
                      >
                      > We played Planning Poker for the 1st time and I had following
                      > concerns.Can you experienced SCUM guys help me ? Please apologize me
                      > if the questions sound bit awkward, Im still trying to get in to the
                      > whole game..In my country there is no SCRUM training yet.
                      >
                      > 1. When Moderator reads 1 story we kept playing Poker and came out of
                      > an estimation to that specific story., But when we went through the PB
                      > more and more., team wanted to revise the previous story estimates
                      > again as its a comparative thing., How do you handle this situation?
                      > Do you get the team to analyze the PB before coming to Planning poker
                      > so they will be more or less accurate with their comparative guess
                      > with other user stories in the rest of the product backlog?
                      >
                      > 2.There was one user story which we had to purchase some device for
                      > that. Scrum master ask where do we do the procurement management,
                      > planning , Cost estimation etc, Will SCRUM has some guidelines for
                      > procurement management for the project.
                      >
                      > 3. Customer who acted as the product owner didnt have answers for some
                      > of the questions.. there were situations such as I need to check with
                      > my infrastructure guys.. I need to ask my BI manager etc. How do you
                      > tackle that situation?
                      >
                      > 4. for certain stories we felt that we need the use cases or further
                      > analysis before thinking of their weight. ..
                      >
                      > 5. Looking at from the Project Office I saw many team for many
                      > projects they had different type of assessments. As an Example., same
                      > story "User needs to log in to the site and fill the registration
                      > form" was rated by the Team A as 5 and Team B as 20.. so how do I
                      > compare and see each team performance from the top when I look at my
                      > teams product burn down charts?
                      >
                      >
                      > Thanks a lot for your help
                      >
                      > Thush
                      >
                      Here are my two-cents to your numbered questions (you get what you
                      paid for):
                      1. I think its fine if the team wants to revisit a
                      previously-estimated story. What's the harm? Better that they know
                      they have the freedom to do whatever it takes to complete their
                      estimates. And they should of course feel free to look at and analyze
                      the Product Backlog whenever they like - that's one of the purposes of
                      having a PB.
                      2. SCRUM has no specific advice that I know of on how to estimate
                      procurement management stories: the team uses what knowledge it has
                      to estimate stories. If a team member has previously worked on a
                      procurement management story, that's great. If not, hey, there's
                      nothing wrong with making a rough estimate (i.e., "guess") - that's
                      what estimating is all about.
                      3. When the Product Owner can't answer a question that the
                      development team needs an answer for, he/she says "I don't know - let
                      me get back to you." If the planning session is long enough, maybe
                      the Product Owner will have the answer within the session (perhaps by
                      phoning somebody); otherwise, you might have to meet again later,
                      after he/she has found the answer. Or, maybe it's decided that it is
                      not that critical to have the answer, and that the estimate can still
                      be made. Of course, to prevent this situation, the Product Owner
                      might invite a Subject Matter Expert to the planning session.
                      4. It's better to get a story estimate out, even if it is very rough.
                      Remember, the team will get a better handle on a story's effort once
                      they begin to task it out.
                      5. Velocity's from different teams are not comparable! The only
                      measure that should count is: did the team have a successful iteration?
                      4.
                    • Alireza Haghighatkhah
                      Three Reason to use Planning Poker Technique: 1. Fosters collaboration by engaging entire team 2. Creates consensus estimate rather than having a single person
                      Message 10 of 19 , Nov 13, 2009
                      • 0 Attachment
                        Three Reason to use Planning Poker Technique:

                        1. Fosters collaboration by engaging entire team
                        2. Creates consensus estimate rather than having a single person driving the estimate
                        3. Exposes issues early through discussion of each user story

                        An Introduction to Planning Poker:
                        http://agile.dzone.com/articles/introduction-planning-poker
                      • redbull1214
                        Agreed. Just to add to this discussion, I tend to emphasize the use of Planning Poker with new scrum teams who need to learn the dynamic of discussing
                        Message 11 of 19 , Nov 13, 2009
                        • 0 Attachment
                          Agreed.

                          Just to add to this discussion, I tend to emphasize the use of Planning Poker with new scrum teams who need to learn the dynamic of discussing requirements and negotiating consensus of value.

                          After about 3-5 sprints, the entire team will start to "speak each other's language" and the scoring becomes nearly unanimous (where the majority of team members agree on the same story point value on the first flip of the cards).

                          When this happens, I give the teams the opportunity to remove use of the cards and replace it with direct discussion--however, there are those who choose to keep using the cards because they enjoy the experience and see benefit from it.


                          James

                          --- In scrumdevelopment@yahoogroups.com, "Alireza Haghighatkhah" <alireza.haghighatkhah@...> wrote:
                          >
                          > Three Reason to use Planning Poker Technique:
                          >
                          > 1. Fosters collaboration by engaging entire team
                          > 2. Creates consensus estimate rather than having a single person driving the estimate
                          > 3. Exposes issues early through discussion of each user story
                          >
                          > An Introduction to Planning Poker:
                          > http://agile.dzone.com/articles/introduction-planning-poker
                          >
                        • Maurice le Rutte
                          redbull1214 schreef: After about 3-5 sprints, the entire team will start to speak each other s language and the scoring becomes nearly unanimous (where the
                          Message 12 of 19 , Nov 15, 2009
                          • 0 Attachment
                            redbull1214 schreef:
                             

                            After about 3-5 sprints, the entire team will start to "speak each other's language" and the scoring becomes nearly unanimous (where the majority of team members agree on the same story point value on the first flip of the cards).

                            When this happens, I give the teams the opportunity to remove use of the cards and replace it with direct discussion-- however, there are those who choose to keep using the cards because they enjoy the experience and see benefit from it.

                            If the scoring becomes unanimous then why still the need for discussion? If the scoring becomes unanimous then why still provide the estimates as a team?

                            Maurice.
                            -- 
                            http://twitter.com/scrumnl
                          • Adam Sroka
                            On Sun, Nov 15, 2009 at 1:16 AM, Maurice le Rutte ... Because the discussion was always the point. The scoring is incidental. What matters is that the team
                            Message 13 of 19 , Nov 15, 2009
                            • 0 Attachment
                              On Sun, Nov 15, 2009 at 1:16 AM, Maurice le Rutte
                              <maurice.lerutte@...> wrote:
                              >
                              >
                              >
                              > redbull1214 schreef:
                              >
                              >
                              >
                              > After about 3-5 sprints, the entire team will start to "speak each other's language" and the scoring becomes nearly unanimous (where the majority of team members agree on the same story point value on the first flip of the cards).
                              >
                              > When this happens, I give the teams the opportunity to remove use of the cards and replace it with direct discussion--however, there are those who choose to keep using the cards because they enjoy the experience and see benefit from it.
                              >
                              > If the scoring becomes unanimous then why still the need for discussion? If the scoring becomes unanimous then why still provide the estimates as a team?
                              >

                              Because the discussion was always the point. The scoring is
                              incidental. What matters is that the team develops a shared
                              understanding of what needs to be done and what it will take to do it.
                              The numbers facilitate that for newer teams because outliers help to
                              identify assumptions and oversights. In other words, if you think it
                              will take a lot more effort than I do, why? What am I missing? If I
                              think it will take a lot less, why? What assumptions am I making?

                              When the team develops a rapport they will be more willing to
                              volunteer their opinions, so forcing outliers to explain themselves
                              won't be necessary. Then you don't need the cards.

                              What I think a lot of teams new to planning poker miss is the idea
                              that consensus isn't the point. Shared understanding is the point. If
                              you automatically say, "I thought it was an eight, but I'll go with
                              five since everyone else did," Then you aren't being polite. You are
                              cheating your teammates out of an opportunity to learn something.

                              Also, the numbers really don't matter. We don't want to have a great
                              degree of variation in the sizes of stories, and if we don't then we
                              can just count stories and get our velocity or cycle time from that.
                              If we do have variation then we need to get better at splitting
                              stories into smaller bits that have value individually. If we can't
                              get that discipline then our velocity will continue to be unstable
                              whether we estimate in points or not.
                            • Maurice le Rutte
                              Adam Sroka schreef: Because the discussion was always the point. The scoring is incidental. What matters is that the team develops a shared understanding of
                              Message 14 of 19 , Nov 15, 2009
                              • 0 Attachment
                                Adam Sroka schreef:
                                 

                                Because the discussion was always the point. The scoring is
                                incidental. What matters is that the team develops a shared
                                understanding of what needs to be done and what it will take to do it.
                                The numbers facilitate that for newer teams because outliers help to
                                identify assumptions and oversights. In other words, if you think it
                                will take a lot more effort than I do, why? What am I missing? If I
                                think it will take a lot less, why? What assumptions am I making?

                                If the actual size isn't important then why wouldn't you defer this type of questions to the sprint planning? Why is it necessary to identify it at this moment?

                                When the team develops a rapport they will be more willing to
                                volunteer their opinions, so forcing outliers to explain themselves
                                won't be necessary. Then you don't need the cards.

                                What I think a lot of teams new to planning poker miss is the idea
                                that consensus isn't the point. Shared understanding is the point. If
                                you automatically say, "I thought it was an eight, but I'll go with
                                five since everyone else did," Then you aren't being polite. You are
                                cheating your teammates out of an opportunity to learn something.

                                Consensus isn't the point, but you want to have a single score anyway, so somebody has to adapt his opinion. If the team member only does it because the others said so it is a pity, if he really feels it is wrong he should tell the others why, but if the others still don't agree, then what?


                                Also, the numbers really don't matter. We don't want to have a great
                                degree of variation in the sizes of stories, and if we don't then we
                                can just count stories and get our velocity or cycle time from that.
                                If we do have variation then we need to get better at splitting
                                stories into smaller bits that have value individually.

                                If you need to break up your stories to have equal sizes you are basically doing an analysis early, otherwise how can you decide how to split the story wisely? If you try to avoid variation than you don't need a poker session as you can explain the details once you are really going to process it, thus the sprint planning session.

                                I would expect the backlog to be varying in size. I would epics [=very large sized] to be lower down the backlog, to have it small items to medium, some even large, sized items in the near future.

                                If we can't
                                get that discipline then our velocity will continue to be unstable
                                whether we estimate in points or not.

                                If I meet a team that claims to have a stable velocity I raise my eyebrows. I would expect a team to 'sometimes undercommit, sometimes overcommit'. A stable velocity is very easy to reach: undercommit. Stableness isn't a goal, it is a strategy to cope with uncertainty by insulating for complexiness.

                                Maurice.
                                http://twitter.com/scrumnl
                              Your message has been successfully submitted and would be delivered to recipients shortly.