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

Planning Poker and estimates by specialists

Expand Messages
  • gustavonarea_tech
    Hello everyone, We re small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can
    Message 1 of 17 , May 3, 2012
    • 0 Attachment
      Hello everyone,

      We're small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can you please tell me whether we're doing anything wrong and how to improve?

      We have four roles in the team: UI designer (1 person), tester (1 person), front-end developer (HTML+CSS; 1 person) and back-end developer (3 people). Each of us play one role, but we're not precious about it: If a back-end developer has to do some testing, for instance, they'll do it.

      The question really is: How are we supposed to estimate an entire user story when we wouldn't know the effort it'd require from other members of the team? For example, a back-end developer wouldn't know how much time the UI designer would need to design an interface -- They'd only know roughly how much time it'd take for them to implement the back-end for it.

      The way we have done it so far is as follows:
      - The user story is presented by the Product Owner.
      - The solution for the user story is discussed from a high-level perspective.
      - We get the UI designer to estimate how much time he'd need to design the solution (considering initial deliverables, conversations with business stakeholders, potential rework on initial deliverables, among other things).
      - We get the front-end developer to estimate how much time he'd need to implement the design in the front-end.
      - We get back-end developers to play planning poker to estimate the developer time required to do the back-end work.
      - We get the tester to estimate the effort to (1) help the relevant stakeholders validate the implementation and (2) verify the implementation.

      At the end of this process, we add up the four estimates and that becomes the estimate for the user story.

      Now, from what I've read and understood, the planning poker is supposed to be done by the whole team, which doesn't make much sense to me as explained above.

      What do you people think?

      Thanks in advance!

      Gustavo Narea.
      http://gustavonarea.net
    • Kurt Häusler
      ... I am assuming you are estimating in story points. You are not actually estimating the time anything takes, or the effort involved, you are estimating the
      Message 2 of 17 , May 8, 2012
      • 0 Attachment
        On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:

        > The question really is: How are we supposed to estimate an entire user
        > story when we wouldn't know the effort it'd require from other members of
        > the team? For example, a back-end developer wouldn't know how much time the
        > UI designer would need to design an interface -- They'd only know roughly
        > how much time it'd take for them to implement the back-end for it.

        I am assuming you are estimating in story points.

        You are not actually estimating the time anything takes, or the effort
        involved, you are estimating the size of the user story compared to
        other stories.

        The time things actually take is incorporated into your velocity metric.

        Usually the size of a user story is independent of any actual
        technical work that may be involved in the solution, in fact when
        stories are estimated, you don't know what the solution is. People
        only start to think about the solution in the second part of the
        sprint planning meeting.

        Usually these stories are not formulated as "do this backend thing,
        then design this interface" anyway are they? They are expressed in
        terms that the customer understand, what a type of user would like to
        achieve and why. Think, how big is the problem that the customer has,
        rather than how much effort should be involved to solve it.

        This way even non-technical members of the team can take part in planning poker.
      • Steve
        I m with Kurt Stop discussing how long something will take and start thinking about the size and complexity Your first round voting will show up differences
        Message 3 of 17 , May 8, 2012
        • 0 Attachment
          I'm with Kurt

          Stop discussing how long something will take and start thinking about the 'size and complexity'

          Your first round voting will show up differences of opinion; this is where you take the opportunity to discuss and understand others view of the 'size and complexity' and then vote again.

          I always suggest that teams have no more than 3 votes on any PBI; if it is considered that more than 3 votes are need, then ther is not enough information in the room to succesfully estimate the PBI.

          BTW, you do not mention whether there are any business people in your Planning Poker sessions - there should be! They do not have a vote but they should be there to aid the discussion.


          --- In scrumdevelopment@yahoogroups.com, "gustavonarea_tech" <me@...> wrote:
          >
          > Hello everyone,
          >
          > We're small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can you please tell me whether we're doing anything wrong and how to improve?
          >
          > We have four roles in the team: UI designer (1 person), tester (1 person), front-end developer (HTML+CSS; 1 person) and back-end developer (3 people). Each of us play one role, but we're not precious about it: If a back-end developer has to do some testing, for instance, they'll do it.
          >
          > The question really is: How are we supposed to estimate an entire user story when we wouldn't know the effort it'd require from other members of the team? For example, a back-end developer wouldn't know how much time the UI designer would need to design an interface -- They'd only know roughly how much time it'd take for them to implement the back-end for it.
          >
          > The way we have done it so far is as follows:
          > - The user story is presented by the Product Owner.
          > - The solution for the user story is discussed from a high-level perspective.
          > - We get the UI designer to estimate how much time he'd need to design the solution (considering initial deliverables, conversations with business stakeholders, potential rework on initial deliverables, among other things).
          > - We get the front-end developer to estimate how much time he'd need to implement the design in the front-end.
          > - We get back-end developers to play planning poker to estimate the developer time required to do the back-end work.
          > - We get the tester to estimate the effort to (1) help the relevant stakeholders validate the implementation and (2) verify the implementation.
          >
          > At the end of this process, we add up the four estimates and that becomes the estimate for the user story.
          >
          > Now, from what I've read and understood, the planning poker is supposed to be done by the whole team, which doesn't make much sense to me as explained above.
          >
          > What do you people think?
          >
          > Thanks in advance!
          >
          > Gustavo Narea.
          > http://gustavonarea.net
          >
        • Steve Ropa
          Agreed. I like to point out that we are estimating how big this story is without regard as to who may or may not end up working on it. I would much rather
          Message 4 of 17 , May 8, 2012
          • 0 Attachment

            Agreed.  I like to point out that we are estimating how big this story is without regard as to who may or may not end up working on it.  I would much rather the team learn to ignore the artificial barriers such as who is a specialist in what.  After all, we aren’t going to stop all production just because the person who originally estimated the back end all of a sudden couldn’t do it are we?

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Kurt Häusler
            Sent: Tuesday, May 08, 2012 7:55 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists

             

             

            On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:

            > The question really is: How are we supposed to estimate an entire user
            > story when we wouldn't know the effort it'd require from other members of
            > the team? For example, a back-end developer wouldn't know how much time the
            > UI designer would need to design an interface -- They'd only know roughly
            > how much time it'd take for them to implement the back-end for it.

            I am assuming you are estimating in story points.

            You are not actually estimating the time anything takes, or the effort
            involved, you are estimating the size of the user story compared to
            other stories.

            The time things actually take is incorporated into your velocity metric.

            Usually the size of a user story is independent of any actual
            technical work that may be involved in the solution, in fact when
            stories are estimated, you don't know what the solution is. People
            only start to think about the solution in the second part of the
            sprint planning meeting.

            Usually these stories are not formulated as "do this backend thing,
            then design this interface" anyway are they? They are expressed in
            terms that the customer understand, what a type of user would like to
            achieve and why. Think, how big is the problem that the customer has,
            rather than how much effort should be involved to solve it.

            This way even non-technical members of the team can take part in planning poker.

          • Charles Bradley - Scrum Coach CSP CSM PSM
            Gustavo, First of all, congratulations to creating a culture where team members are willing to pitch in and help on other specialties.   That s a great
            Message 5 of 17 , May 8, 2012
            • 0 Attachment
              Gustavo,

              First of all, congratulations to creating a culture where team members are willing to pitch in and help on other "specialties."  That's a great accomplishment!  Some people like to discourage the term "specialty" or "specialists" and instead prefer a term like "area of focus", "everyone on a Scrum is a 'developer'", etc.  As long as a team has a "pitch in" attitude like yours and doesn't go the "silo route," I don't care what they call it, so I'll continue to use your term, "specialist."

              Second, what you describe sounds to me like a Waterfall/Planning Poker Hybrid, and to me is a bad smell of a possible Waterfall back slide.  (i.e. sliding back into Waterfall habits)

              I think your implementation is incorrect, and probably defeats a couple of the main features of Planning Poker(PP), namely
              • PP is designed so that all of the team member's estimates are revealed at the same time, so as to avoid "estimate anchoring"
              • PP is designed so that quick consensus on the estimate is the goal, not discussion of the full solution
                • This saves time for the purposes of estimating.
              • PP is designed so that estimates are owned by the team as a whole, not by a bunch of individuals or from a bunch of individual estimates
              Here would be my recommendations:
              • Have the team do planning poker the way it was designed.  Here is a good description of the practice by Mike Cohn: http://planningpoker.com/detail.html
              • Communicate to the team that they are all going to estimate based on the entire work involved for the story, as a team.
                • I find it also sometimes helps to say "Estimate for a mythical 'average' team member that represents the average performance/speed of implementation of everyone on the team"
              • Communicate to the team that the first round of estimates, for a while, will probably be off by large amounts.  Communicate that this is actually excellent(!), because it fosters communication between the specialists and the whole team learns why different kinds of stories take differing amounts of time in the "specialties."
                • After some quick communication is had between the specialists(~2-3 minutes), do another round of Planning Poker.  2-3 more minutes of Planning Poker and hopefully on the 3rd time you are very close to convergence on the estimates.
              • After a few sprints of this, the team usually gets really good at estimating and taking into account things that might add overall time even in other specialties!  This has two benefits:
                • 1.  Estimation becomes *much* faster
                • 2.  If a specialist is absent from the meeting (sick, vacation, etc), often times the team will be able to be fairly accurate in the whole team estimate even without the specialist!
                  • I should also mention that if the same specialist is not going to be able to perform their work this Sprint (due to absence), then the team can take into account that the 'average team member' might be slowed due to lack of expertise in that specialty.  (Or, you can ignore this factor if it is rare -- either approach generally works ok so long as the absences are pretty rare)
              • I would encourage your team to minimize design/solution discussion to the smallest amount is that is necessary to estimate.  I would encourage your team to skip that step and instead *only* discuss it after the first round of estimating.  If the first round estimate has convergence, then no need to discuss solution at all!
              Hope this helps, Gustavo!  Let us know if you have questions or need more help!

              -------
              Charles Bradley
              http://www.ScrumCrazy.com




              From: gustavonarea_tech <me@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Thursday, May 3, 2012 10:12 AM
              Subject: [scrumdevelopment] Planning Poker and estimates by specialists

              Hello everyone,

              We're small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can you please tell me whether we're doing anything wrong and how to improve?

              We have four roles in the team: UI designer (1 person), tester (1 person), front-end developer (HTML+CSS; 1 person) and back-end developer (3 people). Each of us play one role, but we're not precious about it: If a back-end developer has to do some testing, for instance, they'll do it.

              The question really is: How are we supposed to estimate an entire user story when we wouldn't know the effort it'd require from other members of the team? For example, a back-end developer wouldn't know how much time the UI designer would need to design an interface -- They'd only know roughly how much time it'd take for them to implement the back-end for it.

              The way we have done it so far is as follows:
              - The user story is presented by the Product Owner.
              - The solution for the user story is discussed from a high-level perspective.
              - We get the UI designer to estimate how much time he'd need to design the solution (considering initial deliverables, conversations with business stakeholders, potential rework on initial deliverables, among other things).
              - We get the front-end developer to estimate how much time he'd need to implement the design in the front-end.
              - We get back-end developers to play planning poker to estimate the developer time required to do the back-end work.
              - We get the tester to estimate the effort to (1) help the relevant stakeholders validate the implementation and (2) verify the implementation.

              At the end of this process, we add up the four estimates and that becomes the estimate for the user story.

              Now, from what I've read and understood, the planning poker is supposed to be done by the whole team, which doesn't make much sense to me as explained above.

              What do you people think?

              Thanks in advance!

              Gustavo Narea.
              http://gustavonarea.net



              ------------------------------------

              To Post a message, send it to:  scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/scrumdevelopment/

              <*> Your email settings:
                  Individual Email | Traditional

              <*> To change settings online go to:
                  http://groups.yahoo.com/group/scrumdevelopment/join
                  (Yahoo! ID required)

              <*> To change settings via email:
                  scrumdevelopment-digest@yahoogroups.com
                  scrumdevelopment-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                  scrumdevelopment-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                  http://docs.yahoo.com/info/terms/



            • Charles Bradley - Scrum Coach CSP CSM PSM
              Kurt, I have some comments about your comments: You are not actually estimating the time anything takes, or the effort involved, you are estimating the
              Message 6 of 17 , May 8, 2012
              • 0 Attachment
                Kurt,

                I have some comments about your comments:

                <snip>
                You are not actually estimating the time anything takes, or the effort
                involved, you are estimating the size of the user story compared to
                other stories.
                </snip>
                <snip>
                Think, how big is the problem that the customer has,
                rather than how much effort should be involved to solve it.
                </snip>

                While I agree that relative estimation is a good thing, I believe that story points, by definition, are an estimation of the effort/size/time involved for the developers, not the customers, to solve the problem by implementing a software feature.  More here:
                http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

                <snip>
                Usually the size of a user story is independent of any actual
                technical work that may be involved in the solution, in fact when
                stories are estimated, you don't know what the solution is. People
                only start to think about the solution in the second part of the
                sprint planning meeting.
                </snip>

                I don't really agree with this either.  I hope people are thinking about the solution and technical aspects when they give estimates, because that's what we want to know -- how much effort/relative time will be involved in implementing the solution.  While I'm fine with them thinking about the solution in their head, they don't need to discuss a *specific solution*, and any *solution discussion* should be minimized to the amount absolutely necessary to come to a fairly quick Planning Poker estimate.

                <snip>
                This way even non-technical members of the team can take part in planning poker.
                </snip>

                The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                • playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                • the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                -------
                Charles Bradley
                http://www.ScrumCrazy.com




                From: Kurt Häusler <kurt.haeusler@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Tuesday, May 8, 2012 7:54 AM
                Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists

                On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:

                > The question really is: How are we supposed to estimate an entire user
                > story when we wouldn't know the effort it'd require from other members of
                > the team? For example, a back-end developer wouldn't know how much time the
                > UI designer would need to design an interface -- They'd only know roughly
                > how much time it'd take for them to implement the back-end for it.

                I am assuming you are estimating in story points.

                You are not actually estimating the time anything takes, or the effort
                involved, you are estimating the size of the user story compared to
                other stories.

                The time things actually take is incorporated into your velocity metric.

                Usually the size of a user story is independent of any actual
                technical work that may be involved in the solution, in fact when
                stories are estimated, you don't know what the solution is. People
                only start to think about the solution in the second part of the
                sprint planning meeting.

                Usually these stories are not formulated as "do this backend thing,
                then design this interface" anyway are they? They are expressed in
                terms that the customer understand, what a type of user would like to
                achieve and why. Think, how big is the problem that the customer has,
                rather than how much effort should be involved to solve it.

                This way even non-technical members of the team can take part in planning poker.


                ------------------------------------

                To Post a message, send it to:  scrumdevelopment@...
                To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                <*> To visit your group on the web, go to:
                    http://groups.yahoo.com/group/scrumdevelopment/

                <*> Your email settings:
                    Individual Email | Traditional

                <*> To change settings online go to:
                    http://groups.yahoo.com/group/scrumdevelopment/join
                    (Yahoo! ID required)

                <*> To change settings via email:
                    scrumdevelopment-digest@yahoogroups.com
                    scrumdevelopment-fullfeatured@yahoogroups.com

                <*> To unsubscribe from this group, send an email to:
                    scrumdevelopment-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                    http://docs.yahoo.com/info/terms/



              • Mark Levison
                ... Non-technical people involved in estimation? They re part of the Team and their work will contribute towards Done , Examples - Non-technical tester - they
                Message 7 of 17 , May 8, 2012
                • 0 Attachment

                  The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                  • playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                  • the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                  These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                  Non-technical people involved in estimation? They're part of the Team and their work will contribute towards "Done",

                  Examples
                  - Non-technical tester - they know testing, but not development
                  - Documentation writer - the team includes documentation in their definition of done
                  ...

                  Cheers
                  Mark Levison
                  Certified Rablerouser
                • Charles Bradley - Scrum Coach CSP CSM PSM
                  Good examples Mark. I agree with the documentation person(also rare) as an example.  As to so called non technical testers -- in my opinion, all software
                  Message 8 of 17 , May 8, 2012
                  • 0 Attachment
                    Good examples Mark.

                    I agree with the documentation person(also rare) as an example. 

                    As to so called "non technical" testers -- in my opinion, all software testers are technical, even if they are so by "osmosis" of working with technical people on a daily basis.

                    (Again, so long as they are on the Dev Team) (<-- Note that I'm using the 2011 Scrum Guide term "Development Team" which was formerly called "The Team" in previous Scrum Guides)
                     
                    -------
                    Charles Bradley
                    http://www.ScrumCrazy.com




                    From: Mark Levison <mark@...>
                    To: scrumdevelopment@yahoogroups.com
                    Sent: Wednesday, May 9, 2012 12:10 AM
                    Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists






                    The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                    • playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                    • the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                    These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                    Non-technical people involved in estimation? They're part of the Team and their work will contribute towards "Done",

                    Examples
                    - Non-technical tester - they know testing, but not development
                    - Documentation writer - the team includes documentation in their definition of done
                    ...

                    Cheers
                    Mark Levison
                    Certified Rablerouser




                  • Steve
                    ... Sort of depends exactly what you mean by take part in ! Without someone form the business who knows some of the detail of the User Story, the technical
                    Message 9 of 17 , May 9, 2012
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                      > The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                      >
                      > * playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                      > * the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                      > These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                      Sort of depends exactly what you mean by 'take part in'! Without someone form the 'business who knows some of the detail of the User Story, the technical people could discuss all day without having the real knowledge and come up with all sorts of misconceptions.

                      I humbly suggest that statements/questions such as yours may lead newbies to believe that only development team members are in the room during planning poker; I further, not so humbly assert, that this is not the case!
                      >
                      >
                      > -------
                      > Charles Bradley
                      > http://www.ScrumCrazy.com
                      >
                      >
                      >
                      >
                      >
                      > >________________________________
                      > > From: Kurt Häusler <kurt.haeusler@...>
                      > >To: scrumdevelopment@yahoogroups.com
                      > >Sent: Tuesday, May 8, 2012 7:54 AM
                      > >Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists
                      > >
                      > >On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:
                      > >
                      > >> The question really is: How are we supposed to estimate an entire user
                      > >> story when we wouldn't know the effort it'd require from other members of
                      > >> the team? For example, a back-end developer wouldn't know how much time the
                      > >> UI designer would need to design an interface -- They'd only know roughly
                      > >> how much time it'd take for them to implement the back-end for it.
                      > >
                      > >I am assuming you are estimating in story points.
                      > >
                      > >You are not actually estimating the time anything takes, or the effort
                      > >involved, you are estimating the size of the user story compared to
                      > >other stories.
                      > >
                      > >The time things actually take is incorporated into your velocity metric.
                      > >
                      > >Usually the size of a user story is independent of any actual
                      > >technical work that may be involved in the solution, in fact when
                      > >stories are estimated, you don't know what the solution is. People
                      > >only start to think about the solution in the second part of the
                      > >sprint planning meeting.
                      > >
                      > >Usually these stories are not formulated as "do this backend thing,
                      > >then design this interface" anyway are they? They are expressed in
                      > >terms that the customer understand, what a type of user would like to
                      > >achieve and why. Think, how big is the problem that the customer has,
                      > >rather than how much effort should be involved to solve it.
                      > >
                      > >This way even non-technical members of the team can take part in planning poker.
                      > >
                      > >
                      > >------------------------------------
                      > >
                      > >To Post a message, send it to:  scrumdevelopment@...
                      > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                      > >
                      > >
                      > >
                      > >
                      > >
                      > >
                      >
                    • gustavonarea_tech
                      Hi Kurt, ... Yes, one story point is an ideal day of work for one person. ... Isn t that called triangulation and serves a different purpose? According to
                      Message 10 of 17 , May 9, 2012
                      • 0 Attachment
                        Hi Kurt,

                        Thanks for your response! My reply is below:

                        --- In scrumdevelopment@yahoogroups.com, Kurt Häusler <kurt.haeusler@...> wrote:
                        >
                        > On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:
                        >
                        > > The question really is: How are we supposed to estimate an entire user
                        > > story when we wouldn't know the effort it'd require from other members of
                        > > the team? For example, a back-end developer wouldn't know how much time the
                        > > UI designer would need to design an interface -- They'd only know roughly
                        > > how much time it'd take for them to implement the back-end for it.
                        >
                        > I am assuming you are estimating in story points.

                        Yes, one story point is an ideal day of work for one person.


                        > You are not actually estimating the time anything takes, or the effort
                        > involved, you are estimating the size of the user story compared to
                        > other stories.

                        Isn't that called "triangulation" and serves a different purpose? According to Mike Cohn in "User Stories Applied", triangulation refers to "estimating a story based on its relationship to one or more other stories" and its purpose is "for a team to verify that they aren't gradually altering the meaning of a story point".


                        > Usually the size of a user story is independent of any actual
                        > technical work that may be involved in the solution, in fact when
                        > stories are estimated, you don't know what the solution is. People
                        > only start to think about the solution in the second part of the
                        > sprint planning meeting.

                        I think that only applies to teams using a different unit for the story points, like complexity, doesn't it?

                        I can imagine estimating the complexity of a user story without knowing the solution, but I cannot imagine estimating the size of a story without knowing the solution (surely what you'd estimate would be the effort to implement the solution).


                        > Usually these stories are not formulated as "do this backend thing,
                        > then design this interface" anyway are they? They are expressed in
                        > terms that the customer understand, what a type of user would like to
                        > achieve and why. Think, how big is the problem that the customer has,
                        > rather than how much effort should be involved to solve it.
                        >
                        > This way even non-technical members of the team can take part in planning poker.

                        I think that also applies to teams using a unit like complexity for their story points, but doesn't apply to effort-oriented story points like "ideal day of work for one person".

                        Are you recommending the use of complexity-oriented story points instead of effort-oriented ones? If so, can you please elaborate on its advantages?

                        Thanks!
                      • gustavonarea_tech
                        Hi Steve. Thanks for your response. You too seem to support the use of complexity for story points, as opposed to time/effort. We use time/effort for the
                        Message 11 of 17 , May 9, 2012
                        • 0 Attachment
                          Hi Steve.

                          Thanks for your response.

                          You too seem to support the use of complexity for story points, as opposed to time/effort.

                          We use time/effort for the reasons explained by Mike Cohn* and have read material supporting the use of complexity, but honestly I've found Mike's arguments compelling enough for me.

                          I'm starting to think that maybe my concerns come down to two questions:
                          1.- Are effort-oriented story points the best unit for our team?
                          2.- If effort-oriented story points are the best unit for us to use, how can we improve the way estimates are done (see original post)?

                          On the other hand, to answer your question about business people: The PO stays with us throughout the planning meeting, and depending on the project, more business stakeholders join him.

                          Cheers,

                          - Gustavo.

                          * http://www.mountaingoatsoftware.com/blog/its-effort-not-complexity




                          --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@...> wrote:
                          >
                          > I'm with Kurt
                          >
                          > Stop discussing how long something will take and start thinking about the 'size and complexity'
                          >
                          > Your first round voting will show up differences of opinion; this is where you take the opportunity to discuss and understand others view of the 'size and complexity' and then vote again.
                          >
                          > I always suggest that teams have no more than 3 votes on any PBI; if it is considered that more than 3 votes are need, then ther is not enough information in the room to succesfully estimate the PBI.
                          >
                          > BTW, you do not mention whether there are any business people in your Planning Poker sessions - there should be! They do not have a vote but they should be there to aid the discussion.
                          >
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "gustavonarea_tech" <me@> wrote:
                          > >
                          > > Hello everyone,
                          > >
                          > > We're small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can you please tell me whether we're doing anything wrong and how to improve?
                          > >
                          > > We have four roles in the team: UI designer (1 person), tester (1 person), front-end developer (HTML+CSS; 1 person) and back-end developer (3 people). Each of us play one role, but we're not precious about it: If a back-end developer has to do some testing, for instance, they'll do it.
                          > >
                          > > The question really is: How are we supposed to estimate an entire user story when we wouldn't know the effort it'd require from other members of the team? For example, a back-end developer wouldn't know how much time the UI designer would need to design an interface -- They'd only know roughly how much time it'd take for them to implement the back-end for it.
                          > >
                          > > The way we have done it so far is as follows:
                          > > - The user story is presented by the Product Owner.
                          > > - The solution for the user story is discussed from a high-level perspective.
                          > > - We get the UI designer to estimate how much time he'd need to design the solution (considering initial deliverables, conversations with business stakeholders, potential rework on initial deliverables, among other things).
                          > > - We get the front-end developer to estimate how much time he'd need to implement the design in the front-end.
                          > > - We get back-end developers to play planning poker to estimate the developer time required to do the back-end work.
                          > > - We get the tester to estimate the effort to (1) help the relevant stakeholders validate the implementation and (2) verify the implementation.
                          > >
                          > > At the end of this process, we add up the four estimates and that becomes the estimate for the user story.
                          > >
                          > > Now, from what I've read and understood, the planning poker is supposed to be done by the whole team, which doesn't make much sense to me as explained above.
                          > >
                          > > What do you people think?
                          > >
                          > > Thanks in advance!
                          > >
                          > > Gustavo Narea.
                          > > http://gustavonarea.net
                          > >
                          >
                        • Charles Bradley - Scrum Coach CSP CSM PSM
                          ... experience.  I can t imagine any other non-technical person being involved in planning poker. Can you? Steve then commented on my poorly worded
                          Message 12 of 17 , May 9, 2012
                          • 0 Attachment
                            I originally poorly stated:
                            > These occur rarely in my
                            experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                            Steve then commented on my poorly worded statement/question
                            > I humbly suggest that statements/questions such as yours may lead
                            newbies to believe that only development team members are in the room during planning poker;

                            Steve,
                            I agree, and my statements were poorly worded.  Thank you for pointing that out.  Let me try again.

                            Kurt said:
                            > >This way even non-technical members of the team can take part in planning poker.

                            If by "The Team," Kurt was referring to what the Scrum Guide now calls "The Development Team", then I have no issue with what he said.  The Dev Team should be the only people participating in estimating via planning poker.  I, too, agree that other people who are helpful to the conversation can always be present, but they should strongly refrain from influencing the estimates and not be directly involved in estimating via Planning poker(No cards for you!).  These "other people" should only act as "clarifiers" of requirements/acceptance tests, and not influencers of the estimates.

                            I think the rest of my statements about Planning Poker being an estimation of Dev Team effort still stand, and are pretty much the opposite of what Kurt was suggesting when he said:

                            >You are not actually estimating the time anything takes, or the effort involved
                            ...
                            > Think, how big is the problem that the customer has,
                            > rather than how much effort should be involved to solve it.

                            I hope that clarifies some.  The "email machine" and my brain don't always do a great job of communicating.
                             
                            -------
                            Charles Bradley
                            http://www.ScrumCrazy.com




                            From: Steve <steve@...>
                            To: scrumdevelopment@yahoogroups.com
                            Sent: Wednesday, May 9, 2012 5:07 AM
                            Subject: [scrumdevelopment] Re: Planning Poker and estimates by specialists



                            --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                            > The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                            >
                            >     * playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                            >     * the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                            > These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                            Sort of depends exactly what you mean by 'take part in'!  Without someone form the 'business who knows some of the detail of the User Story, the technical people could discuss all day without having the real knowledge and come up with all sorts of misconceptions.

                            I humbly suggest that statements/questions such as yours may lead newbies to believe that only development team members are in the room during planning poker; I further, not so humbly assert, that this is not the case!
                            >
                            >
                            > -------
                            > Charles Bradley
                            > http://www.ScrumCrazy.com
                            >
                            >
                            >
                            >
                            >
                            > >________________________________
                            > > From: Kurt Häusler <kurt.haeusler@...>
                            > >To: scrumdevelopment@yahoogroups.com
                            > >Sent: Tuesday, May 8, 2012 7:54 AM
                            > >Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists
                            > >
                            > >On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:
                            > >
                            > >> The question really is: How are we supposed to estimate an entire user
                            > >> story when we wouldn't know the effort it'd require from other members of
                            > >> the team? For example, a back-end developer wouldn't know how much time the
                            > >> UI designer would need to design an interface -- They'd only know roughly
                            > >> how much time it'd take for them to implement the back-end for it.
                            > >
                            > >I am assuming you are estimating in story points.
                            > >
                            > >You are not actually estimating the time anything takes, or the effort
                            > >involved, you are estimating the size of the user story compared to
                            > >other stories.
                            > >
                            > >The time things actually take is incorporated into your velocity metric.
                            > >
                            > >Usually the size of a user story is independent of any actual
                            > >technical work that may be involved in the solution, in fact when
                            > >stories are estimated, you don't know what the solution is. People
                            > >only start to think about the solution in the second part of the
                            > >sprint planning meeting.
                            > >
                            > >Usually these stories are not formulated as "do this backend thing,
                            > >then design this interface" anyway are they? They are expressed in
                            > >terms that the customer understand, what a type of user would like to
                            > >achieve and why. Think, how big is the problem that the customer has,
                            > >rather than how much effort should be involved to solve it.
                            > >
                            > >This way even non-technical members of the team can take part in planning poker.
                            > >
                            > >
                            > >------------------------------------
                            > >
                            > >To Post a message, send it to:  scrumdevelopment@...
                            > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                            > >
                            > >
                            > >
                            > >
                            > >
                            > >
                            >




                            ------------------------------------

                            To Post a message, send it to:  scrumdevelopment@...
                            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                            <*> To visit your group on the web, go to:
                                http://groups.yahoo.com/group/scrumdevelopment/

                            <*> Your email settings:
                                Individual Email | Traditional

                            <*> To change settings online go to:
                                http://groups.yahoo.com/group/scrumdevelopment/join
                                (Yahoo! ID required)

                            <*> To change settings via email:
                                scrumdevelopment-digest@yahoogroups.com
                                scrumdevelopment-fullfeatured@yahoogroups.com

                            <*> To unsubscribe from this group, send an email to:
                                scrumdevelopment-unsubscribe@yahoogroups.com

                            <*> Your use of Yahoo! Groups is subject to:
                                http://docs.yahoo.com/info/terms/



                          • Steve Ropa
                            I wonder if anyone else has tried giving cards to the “non development team” members. I have found that sometimes you get a very interesting set of
                            Message 13 of 17 , May 9, 2012
                            • 0 Attachment

                              I wonder if anyone else has tried giving cards to the “non development team” members.  I have found that sometimes you get a very interesting set of numbers this way.  I personally am leaning further and further away from estimating at all, but when I do, I like to have anyone who is interested throw numbers into the ring.

                               

                              Now some caveats:

                              1.        The Whole Team needs to be relatively small.  It just doesn’t work if you have dozens of people “voting”.

                              2.       The team needs to be comfortable in their own skin.  The goal is not to have the external stakeholders drive the estimates, but to help drive the conversation around the estimates.

                              3.       I’ve seen this work well, but I don’t expect it would work well for all teams, just some.

                               

                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Charles Bradley - Scrum Coach CSP CSM PSM I
                              Sent: Wednesday, May 09, 2012 9:04 AM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: Re: [scrumdevelopment] Re: Planning Poker and estimates by specialists

                               

                               

                              I originally poorly stated:

                              > These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                               

                              Steve then commented on my poorly worded statement/question

                              > I humbly suggest that statements/questions such as yours may lead newbies to believe that only development team members are in the room during planning poker;

                               

                              Steve,

                              I agree, and my statements were poorly worded.  Thank you for pointing that out.  Let me try again.

                               

                              Kurt said:

                              > >This way even non-technical members of the team can take part in planning poker.


                              If by "The Team," Kurt was referring to what the Scrum Guide now calls "The Development Team", then I have no issue with what he said.  The Dev Team should be the only people participating in estimating via planning poker.  I, too, agree that other people who are helpful to the conversation can always be present, but they should strongly refrain from influencing the estimates and not be directly involved in estimating via Planning poker(No cards for you!).  These "other people" should only act as "clarifiers" of requirements/acceptance tests, and not influencers of the estimates.

                              I think the rest of my statements about Planning Poker being an estimation of Dev Team effort still stand, and are pretty much the opposite of what Kurt was suggesting when he said:

                              >You are not actually estimating the time anything takes, or the effort involved
                              ...
                              > Think, how big is the problem that the customer has,
                              > rather than how much effort should be involved to solve it.

                              I hope that clarifies some.  The "email machine" and my brain don't always do a great job of communicating.

                               

                              -------
                              Charles Bradley
                              http://www.ScrumCrazy.com

                               

                               


                              From: Steve <steve@...>
                              To: scrumdevelopment@yahoogroups.com
                              Sent: Wednesday, May 9, 2012 5:07 AM
                              Subject: [scrumdevelopment] Re: Planning Poker and estimates by specialists




                              --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                              > The only reason, IMO, for a non technical person to take part in planning poker is if they are:
                              >
                              >     * playing the role of analyst(business analyst, etc) or a non technical UI designer, AND
                              >     * the person is on the (Scrum definition of) Development Team, helping turn stories into software.
                              > These occur rarely in my experience.  I can't imagine any other non-technical person being involved in planning poker. Can you?

                              Sort of depends exactly what you mean by 'take part in'!  Without someone form the 'business who knows some of the detail of the User Story, the technical people could discuss all day without having the real knowledge and come up with all sorts of misconceptions.

                              I humbly suggest that statements/questions such as yours may lead newbies to believe that only development team members are in the room during planning poker; I further, not so humbly assert, that this is not the case!
                              >
                              >
                              > -------
                              > Charles Bradley
                              > http://www.ScrumCrazy.com
                              >
                              >
                              >
                              >
                              >
                              > >________________________________
                              > > From: Kurt Häusler <kurt.haeusler@...>
                              > >To: scrumdevelopment@yahoogroups.com
                              > >Sent: Tuesday, May 8, 2012 7:54 AM
                              > >Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists
                              > >
                              > >On Thu, May 3, 2012 at 6:12 PM, gustavonarea_tech <me@...> wrote:
                              > >
                              > >> The question really is: How are we supposed to estimate an entire user
                              > >> story when we wouldn't know the effort it'd require from other members of
                              > >> the team? For example, a back-end developer wouldn't know how much time the
                              > >> UI designer would need to design an interface -- They'd only know roughly
                              > >> how much time it'd take for them to implement the back-end for it.
                              > >
                              > >I am assuming you are estimating in story points.
                              > >
                              > >You are not actually estimating the time anything takes, or the effort
                              > >involved, you are estimating the size of the user story compared to
                              > >other stories.
                              > >
                              > >The time things actually take is incorporated into your velocity metric.
                              > >
                              > >Usually the size of a user story is independent of any actual
                              > >technical work that may be involved in the solution, in fact when
                              > >stories are estimated, you don't know what the solution is. People
                              > >only start to think about the solution in the second part of the
                              > >sprint planning meeting.
                              > >
                              > >Usually these stories are not formulated as "do this backend thing,
                              > >then design this interface" anyway are they? They are expressed in
                              > >terms that the customer understand, what a type of user would like to
                              > >achieve and why. Think, how big is the problem that the customer has,
                              > >rather than how much effort should be involved to solve it.
                              > >
                              > >This way even non-technical members of the team can take part in planning poker.
                              > >
                              > >
                              > >------------------------------------
                              > >
                              > >To Post a message, send it to:  scrumdevelopment@...
                              > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                              > >
                              > >
                              > >
                              > >
                              > >
                              > >
                              >




                              ------------------------------------

                              To Post a message, send it to:  scrumdevelopment@...
                              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                              <*> To visit your group on the web, go to:
                                  http://groups.yahoo.com/group/scrumdevelopment/

                              <*> Your email settings:
                                  Individual Email | Traditional

                              <*> To change settings online go to:
                                  http://groups.yahoo.com/group/scrumdevelopment/join
                                  (Yahoo! ID required)

                              <*> To change settings via email:
                                  scrumdevelopment-digest@yahoogroups.com
                                  scrumdevelopment-fullfeatured@yahoogroups.com

                              <*> To unsubscribe from this group, send an email to:
                                  scrumdevelopment-unsubscribe@yahoogroups.com

                              <*> Your use of Yahoo! Groups is subject to:
                                  http://docs.yahoo.com/info/terms/


                            • Kurt Häusler
                              ... For sure. I meant everyone in the cross-functional team, excluding the PO and SM. In other words the development team. I also worded it poorly when I said
                              Message 14 of 17 , May 9, 2012
                              • 0 Attachment
                                On May 9, 2012, at 5:04 PM, Charles Bradley - Scrum Coach CSP CSM PSM I wrote:

                                >
                                >
                                > Kurt said:
                                > > >This way even non-technical members of the team can take part in planning poker.
                                >
                                > If by "The Team," Kurt was referring to what the Scrum Guide now calls "The Development Team", then I have no issue with what he said. The Dev Team should be the only people participating in estimating via planning poker. I, too, agree that other people who are helpful to the conversation can always be present, but they should strongly refrain from influencing the estimates and not be directly involved in estimating via Planning poker(No cards for you!). These "other people" should only act as "clarifiers" of requirements/acceptance tests, and not influencers of the estimates.

                                For sure. I meant everyone in the cross-functional team, excluding the PO and SM. In other words the development team. I also worded it poorly when I said non-technical team members. I was thinking those team members who are perhaps don't know that much about programming. I was thinking about different types of domain specialists or those involved in creating the non-software parts of the product. I was thinking about tourism products, and energy contracts etc, where software isn't the main product. You might have lawyers, mathematicians (I guess they can be considered technical), scientists in the team. If the product is a car part you might have electronic engineers in the team (definitely technical). I probably should have said non-programmers, as even testers need to be involved in estimation, but if its the solution you are estimating rather than the problem, then even testers are excluded.


                                > I think the rest of my statements about Planning Poker being an estimation of Dev Team effort still stand, and are pretty much the opposite of what Kurt was suggesting when he said:
                                >
                                > >You are not actually estimating the time anything takes, or the effort involved
                                > ...
                                > > Think, how big is the problem that the customer has,
                                > > rather than how much effort should be involved to solve it.

                                Ok, imagine you have two stories, A and B, that are the same size. And two developers X and Y (Y always spends 3 times as much effort on documentation as X). Perhaps you have a software tool that is only licensed for use 1 day in the 2 day sprint. If they can use the tool, effort is halved. If Developer X were to do either A or B on day 1, they would likely involve the same effort. But it is very likely that different amounts of effort will go into delivering a solution to each story.

                                If we are estimating effort, then A and B should have different estimates. We would also have to determine in advance who would do each story and when, which would involve a lot of discussion, and more planning than is appropriate for the time of estimation. My claim is that effort is irrelevant for story point estimate, and only the size should be considered, and both stories should have the same estimates.

                                More abstractly, things pertaining to the problem, or story itself, such as its relative size, can be estimated in advance with story points.
                                Things pertaining to the solution, which is not known in much detail at the time of estimation, such as effort required, time taken, who will do it, and how, can only be measured afterwards, and is incorporated in the velocity metric.

                                But you are right that it is sometimes helpful to think about possible solutions in order to think about the size of a story.

                                But that just helps me, and has seemed to help others. I think if I were to attempt to estimate effort, the best I could come up with would be something like "ideal effort", assuming the average developer, solves it in an average way, on an average day, which is far closer to "size" than "actual effort" I feel using the term effort is misleading. Just call it size.
                              • gustavonarea_tech
                                Hi Charles, Your response is very useful. Thank you very much! It seems to me like the main thing we missed was to estimate as a team, driven by the desire to
                                Message 15 of 17 , May 9, 2012
                                • 0 Attachment
                                  Hi Charles,

                                  Your response is very useful. Thank you very much!

                                  It seems to me like the main thing we missed was to estimate as a team, driven by the desire to be relatively accurate with the estimations early on (which I know is highly discouraged).

                                  Thanks!

                                  - Gustavo.


                                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
                                  >
                                  > Gustavo,
                                  >
                                  > First of all, congratulations to creating a culture where team members are willing to pitch in and help on other "specialties."  That's a great accomplishment!  Some people like to discourage the term "specialty" or "specialists" and instead prefer a term like "area of focus", "everyone on a Scrum is a 'developer'", etc.  As long as a team has a "pitch in" attitude like yours and doesn't go the "silo route," I don't care what they call it, so I'll continue to use your term, "specialist."
                                  >
                                  >
                                  > Second, what you describe sounds to me like a Waterfall/Planning Poker Hybrid, and to me is a bad smell of a possible Waterfall back slide.  (i.e. sliding back into Waterfall habits)
                                  >
                                  > I think your implementation is incorrect, and probably defeats a couple of the main features of Planning Poker(PP), namely
                                  > * PP is designed so that all of the team member's estimates are revealed at the same time, so as to avoid "estimate anchoring"
                                  >
                                  > * PP is designed so that quick consensus on the estimate is the goal, not discussion of the full solution
                                  > * This saves time for the purposes of estimating.
                                  >
                                  > * PP is designed so that estimates are owned by the team as a whole, not by a bunch of individuals or from a bunch of individual estimates
                                  > Here would be my recommendations:
                                  > * Have the team do planning poker the way it was designed.  Here is a good description of the practice by Mike Cohn:http://planningpoker.com/detail.html
                                  > * Communicate to the team that they are all going to estimate based on the entire work involved for the story, as a team.
                                  > * I find it also sometimes helps to say "Estimate for a mythical 'average' team member that represents the average performance/speed of implementation of everyone on the team"
                                  >
                                  > * Communicate to the team that the first round of estimates, for a while, will probably be off by large amounts.  Communicate that this is actually excellent(!), because it fosters communication between the specialists and the whole team learns why different kinds of stories take differing amounts of time in the "specialties."
                                  > * After some quick communication is had between the specialists(~2-3 minutes), do another round of Planning Poker.  2-3 more minutes of Planning Poker and hopefully on the 3rd time you are very close to convergence on the estimates.
                                  > * After a few sprints of this, the team usually gets really good at estimating and taking into account things that might add overall time even in other specialties!  This has two benefits:
                                  > * 1.  Estimation becomes *much* faster
                                  > * 2.  If a specialist is absent from the meeting (sick, vacation, etc), often times the team will be able to be fairly accurate in the whole team estimate even without the specialist!
                                  > * I should also mention that if the same specialist is not going to be able to perform their work this Sprint (due to absence), then the team can take into account that the 'average team member' might be slowed due to lack of expertise in that specialty.  (Or, you can ignore this factor if it is rare -- either approach generally works ok so long as the absences are pretty rare)
                                  > * I would encourage your team to minimize design/solution discussion to the smallest amount is that is necessary to estimate.  I would encourage your team to skip that step and instead *only* discuss it after the first round of estimating.  If the first round estimate has convergence, then no need to discuss solution at all!
                                  > Hope this helps, Gustavo!  Let us know if you have questions or need more help!
                                  >
                                  >
                                  > -------
                                  > Charles Bradley
                                  > http://www.ScrumCrazy.com
                                  >
                                  >
                                  >
                                  >
                                  >
                                  > >________________________________
                                  > > From: gustavonarea_tech <me@...>
                                  > >To: scrumdevelopment@yahoogroups.com
                                  > >Sent: Thursday, May 3, 2012 10:12 AM
                                  > >Subject: [scrumdevelopment] Planning Poker and estimates by specialists
                                  > >
                                  > >Hello everyone,
                                  > >
                                  > >We're small development team maintaining a web application and the way we do planning poker at planning meetings feels a bit strange to me. Can you please tell me whether we're doing anything wrong and how to improve?
                                  > >
                                  > >We have four roles in the team: UI designer (1 person), tester (1 person), front-end developer (HTML+CSS; 1 person) and back-end developer (3 people). Each of us play one role, but we're not precious about it: If a back-end developer has to do some testing, for instance, they'll do it.
                                  > >
                                  > >The question really is: How are we supposed to estimate an entire user story when we wouldn't know the effort it'd require from other members of the team? For example, a back-end developer wouldn't know how much time the UI designer would need to design an interface -- They'd only know roughly how much time it'd take for them to implement the back-end for it.
                                  > >
                                  > >The way we have done it so far is as follows:
                                  > >- The user story is presented by the Product Owner.
                                  > >- The solution for the user story is discussed from a high-level perspective.
                                  > >- We get the UI designer to estimate how much time he'd need to design the solution (considering initial deliverables, conversations with business stakeholders, potential rework on initial deliverables, among other things).
                                  > >- We get the front-end developer to estimate how much time he'd need to implement the design in the front-end.
                                  > >- We get back-end developers to play planning poker to estimate the developer time required to do the back-end work.
                                  > >- We get the tester to estimate the effort to (1) help the relevant stakeholders validate the implementation and (2) verify the implementation.
                                  > >
                                  > >At the end of this process, we add up the four estimates and that becomes the estimate for the user story.
                                  > >
                                  > >Now, from what I've read and understood, the planning poker is supposed to be done by the whole team, which doesn't make much sense to me as explained above.
                                  > >
                                  > >What do you people think?
                                  > >
                                  > >Thanks in advance!
                                  > >
                                  > >Gustavo Narea.
                                  > >http://gustavonarea.net
                                  > >
                                  > >
                                  > >
                                  > >------------------------------------
                                  > >
                                  > >To Post a message, send it to:  scrumdevelopment@...
                                  > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  > >
                                  >
                                • Charles Bradley - Scrum Coach CSP CSM PSM
                                  Kurt, Thanks for the clarifications.  I think once you get to the concept that Planning Poker is a whole team estimate (which I sometimes communicate as
                                  Message 16 of 17 , May 9, 2012
                                  • 0 Attachment
                                    Kurt,

                                    Thanks for the clarifications.  I think once you get to the concept that Planning Poker is a "whole team estimate" (which I sometimes communicate as "average dev team member estimate" to PP newbies as I described before), and that estimates will somewhat follow the law of averages because we do lots of them, you don't need to worry about the difference between terms like "size" and "effort", or who works a particular issue, or what tool license is available on what day.  It also helps if you keep your stories small, as is suggested by the user story practice.
                                     
                                    -------
                                    Charles Bradley
                                    http://www.ScrumCrazy.com




                                    From: Kurt Häusler <kurt.haeusler@...>
                                    To: scrumdevelopment@yahoogroups.com
                                    Sent: Wednesday, May 9, 2012 10:29 AM
                                    Subject: Re: [scrumdevelopment] Planning Poker and estimates by specialists


                                    On May 9, 2012, at 5:04 PM, Charles Bradley - Scrum Coach CSP CSM PSM I wrote:

                                    >
                                    >
                                    > Kurt said:
                                    > > >This way even non-technical members of the team can take part in planning poker.
                                    >
                                    > If by "The Team," Kurt was referring to what the Scrum Guide now calls "The Development Team", then I have no issue with what he said.  The Dev Team should be the only people participating in estimating via planning poker.  I, too, agree that other people who are helpful to the conversation can always be present, but they should strongly refrain from influencing the estimates and not be directly involved in estimating via Planning poker(No cards for you!).  These "other people" should only act as "clarifiers" of requirements/acceptance tests, and not influencers of the estimates.

                                    For sure. I meant everyone in the cross-functional team, excluding the PO and SM. In other words the development team. I also worded it poorly when I said non-technical team members. I was thinking those team members who are perhaps don't know that much about programming. I was thinking about different types of domain specialists or those involved in creating the non-software parts of the product. I was thinking about tourism products, and energy contracts etc, where software isn't the main product. You might have lawyers, mathematicians (I guess they can be considered technical), scientists in the team. If the product is a car part you might have electronic engineers in the team (definitely technical). I probably should have said non-programmers, as even testers need to be involved in estimation, but if its the solution you are estimating rather than the problem, then even testers are excluded.


                                    > I think the rest of my statements about Planning Poker being an estimation of Dev Team effort still stand, and are pretty much the opposite of what Kurt was suggesting when he said:
                                    >
                                    > >You are not actually estimating the time anything takes, or the effort involved
                                    > ...
                                    > > Think, how big is the problem that the customer has,
                                    > > rather than how much effort should be involved to solve it.

                                    Ok, imagine you have two stories, A and B, that are the same size. And two developers X and Y (Y always spends 3 times as much effort on documentation as X). Perhaps you have a software tool that is only licensed for use 1 day in the 2 day sprint. If they can use the tool, effort is halved. If Developer X were to do either A or B on day 1, they would likely involve the same effort. But it is very likely that different amounts of effort will go into delivering a solution to each story.

                                    If we are estimating effort, then A and B should have different estimates. We would also have to determine in advance who would do each story and when, which would involve a lot of discussion, and more planning than is appropriate for the time of estimation. My claim is that effort is irrelevant for story point estimate, and only the size should be considered, and both stories should have the same estimates.

                                    More abstractly, things pertaining to the problem, or story itself, such as its relative size, can be estimated in advance with story points.
                                    Things pertaining to the solution, which is not known in much detail at the time of estimation, such as effort required, time taken, who will do it, and how, can only be measured afterwards, and is incorporated in the velocity metric.

                                    But you are right that it is sometimes helpful to think about possible solutions in order to think about the size of a story.

                                    But that just helps me, and has seemed to help others. I think if I were to attempt to estimate effort, the best I could come up with would be something like "ideal effort", assuming the average developer, solves it in an average way, on an average day, which is far closer to "size" than "actual effort" I feel using the term effort is misleading. Just call it size.

                                    ------------------------------------

                                    To Post a message, send it to:  scrumdevelopment@...
                                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

                                    <*> To visit your group on the web, go to:
                                        http://groups.yahoo.com/group/scrumdevelopment/

                                    <*> Your email settings:
                                        Individual Email | Traditional

                                    <*> To change settings online go to:
                                        http://groups.yahoo.com/group/scrumdevelopment/join
                                        (Yahoo! ID required)

                                    <*> To change settings via email:
                                        scrumdevelopment-digest@yahoogroups.com
                                        scrumdevelopment-fullfeatured@yahoogroups.com

                                    <*> To unsubscribe from this group, send an email to:
                                        scrumdevelopment-unsubscribe@yahoogroups.com

                                    <*> Your use of Yahoo! Groups is subject to:
                                        http://docs.yahoo.com/info/terms/



                                  • Kurt Häusler
                                    ... Ahh yes. I have seen that suggestion. I don t like it. It might be useful for teams that have trouble not being able to deal with the abstract nature of
                                    Message 17 of 17 , May 10, 2012
                                    • 0 Attachment
                                      On May 9, 2012, at 3:33 PM, gustavonarea_tech wrote:

                                      > Yes, one story point is an ideal day of work for one person.

                                      Ahh yes. I have seen that suggestion. I don't like it. It might be useful for teams that have trouble not being able to deal with the abstract nature of story points.

                                      It is also only supposed to be an initial calibration to get started. Teams are supposed to forget that a point started off as an ideal day.

                                      I have seen teams basically use points as synonyms for days, and directly observed all the problems that follow. It completely negates the advantages of using points. People try and find a reason why they only achieved 150 man-hours worth of work when 300 was available in the sprint. Velocity ends up being a percentage of "productive time" versus "meetings and answering emails time". There is a lot of pressure to reduce the so called velocity from say 85% down to a measured value of 75%.

                                      For this reason I am not in favor of suggesting a point has anything to do with time at all, ideal or otherwise.

                                      >
                                      > > You are not actually estimating the time anything takes, or the effort
                                      > > involved, you are estimating the size of the user story compared to
                                      > > other stories.
                                      >
                                      > Isn't that called "triangulation" and serves a different purpose? According to Mike Cohn in "User Stories Applied", triangulation refers to "estimating a story based on its relationship to one or more other stories" and its purpose is "for a team to verify that they aren't gradually altering the meaning of a story point".

                                      For me that is the core of relative estimation. It is not as if a team tries to estimate a story without comparing it to other stories, and then estimating again by comparing it to stories just to verify that the first estimate was ok.

                                      >
                                      > > Usually the size of a user story is independent of any actual
                                      > > technical work that may be involved in the solution, in fact when
                                      > > stories are estimated, you don't know what the solution is. People
                                      > > only start to think about the solution in the second part of the
                                      > > sprint planning meeting.
                                      >
                                      > I think that only applies to teams using a different unit for the story points, like complexity, doesn't it?

                                      What does complexity even mean? To me points are a measure of the size of the problem. I suppose it makes sense to talk about how complex the problem is, but I would not worry too much about the complexity of any potential solutions.

                                      >
                                      > > Usually these stories are not formulated as "do this backend thing,
                                      > > then design this interface" anyway are they? They are expressed in
                                      > > terms that the customer understand, what a type of user would like to
                                      > > achieve and why. Think, how big is the problem that the customer has,
                                      > > rather than how much effort should be involved to solve it.
                                      > >
                                      > > This way even non-technical members of the team can take part in planning poker.
                                      >
                                      > I think that also applies to teams using a unit like complexity for their story points, but doesn't apply to effort-oriented story points like "ideal day of work for one person".
                                      >
                                      > Are you recommending the use of complexity-oriented story points instead of effort-oriented ones? If so, can you please elaborate on its advantages?

                                      I would say story points should be an estimate of the problem rather than any potential solution. For me that is size, but I guess complexity could work for someone, as long as we are talking about complexity of the problem rather than the solution. Effort only applies to the solution so that is why I don't think of effort when estimating a story.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.