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

Re: [scrumdevelopment] User story estimation

Expand Messages
  • Kevin Callahan
    I m a huge fan of the Planning Game, which I learned from Chris Sims @ Agile Learning Labs. They have a post about it here:
    Message 1 of 11 , Jun 14, 2013
    • 0 Attachment
      I'm a huge fan of the Planning Game, which I learned from Chris Sims @ Agile Learning Labs. They have a post about it here:


      This doesn't help at all with prioritization, though you could probably do a similar activity with stakeholders assigning a business value estimate to each story and get a force-ranking of priorities.

      I'm also not entirely sure how these slice against story mapping, which I understand more to be a visualization/exploration of the work required for specific features (and might be a thread hijack, so please point that out if it's true). Though I'd be very interested to hear thoughts on that as well...

      -k

      On Jun 14, 2013, at 11:07 AM, curiouschimp wrote:

       

      Hi all.

      I'd like some feedback on user story and task size estimation.

      Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

      Or those who are 'interested'?

      I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

      I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.


      Kevin Callahan
      Scrum Master & Agile Coach
      LiveWorld Inc.

      Mobile+1 (207) 691-2997
      Emailkcallahan@...
      Skypekevmocal
      Webwww.liveworld.com

      Follow UsFacebook Twitter LinkedIn



    • Jim Rice
      Well put Steve. I m in complete agreement. Seen it; avoid it. Scrum is about a whole team. A team that isn t about being whole, is just a group with holes.
      Message 2 of 11 , Jun 14, 2013
      • 0 Attachment
        Well put Steve. I'm in complete agreement. Seen it; avoid it. Scrum is about a whole team. 
        A team that isn't about being whole, is just a group with holes. It'll never hold water.

        JBo

        Sent from my iPhone

        On Jun 14, 2013, at 11:26 AM, <steveropa@...> wrote:

         

        I really try to get dissolve the idea of domain expertise as quickly as possible.  One way to do that is to ensure that the entire team(not just the engineers) are part of the estimation process.  By allowing the “interested party” approach, you are helping your engineers create silos.  Not only that but you are enabling self destructive behavior as far as their own careers go. 
         
        One thing I really like to stress for those engineers is that each story is a team commitment, even if they expect to be separating into their usual silos.  If nothing else, by estimating together, they can help other team members understand why they think their stories are the size they are...
         
        Steve
         
        Sent from Windows Mail
         
        From: curiouschimp
        Sent: ‎Friday‎, ‎June‎ ‎14‎, ‎2013 ‎9‎:‎07‎ ‎AM
        To: scrumdevelopment@yahoogroups.com
         
         

        Hi all.

        I'd like some feedback on user story and task size estimation.

        Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

        Or those who are 'interested'?

        I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

        I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.

      • Jesse Houwing
        I hear you mention two separate things, task size estimation and userstory estimation. For the story part, prefer the whole team, even though the domain
        Message 3 of 11 , Jun 14, 2013
        • 0 Attachment
          I hear you mention two separate things, task size estimation and userstory estimation. 

          For the story part, prefer the whole team, even though the 'domain expert' might think he knows everything it's good to have input from others to challenge the number. It also prevents people from guesstimating too low numbers, since they already know so much. Or people from forgetting the amount of work the updating of the automated tests, the test data or the deployment scripts is going to take :).

          For tasks you'd still prefer the whole team, but when there is a clear indication on who will do the task (which could be a small, domain bound step in the story) then the 'domain expert' usually has more weight, especially when he comes up with a higher number. We don't usually do planning poker for tasks, since it's, in our case, an estimate in hours and not relative to another task as with user stories. You can do this when your tasks are small enough to be completed in about one day. Usually when a developer or a pair of developers picks up the task, they revisit the original estimation to make sure it's still valid, then update their progress at the end of the day (which usually means they close out the task). The most important thing we agree on as a team is that the story is small enough to be executed in one or two days.


          On Fri, Jun 14, 2013 at 5:26 PM, <steveropa@...> wrote:


          I really try to get dissolve the idea of domain expertise as quickly as possible.  One way to do that is to ensure that the entire team(not just the engineers) are part of the estimation process.  By allowing the “interested party” approach, you are helping your engineers create silos.  Not only that but you are enabling self destructive behavior as far as their own careers go. 
           
          One thing I really like to stress for those engineers is that each story is a team commitment, even if they expect to be separating into their usual silos.  If nothing else, by estimating together, they can help other team members understand why they think their stories are the size they are...
           
          Steve
           
          Sent from Windows Mail
           
          From: curiouschimp
          Sent: ‎Friday‎, ‎June‎ ‎14‎, ‎2013 ‎9‎:‎07‎ ‎AM
          To: scrumdevelopment@yahoogroups.com
           
           

          Hi all.

          I'd like some feedback on user story and task size estimation.

          Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

          Or those who are 'interested'?

          I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

          I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.




        • Kurt Häusler
          Hi, don t bother estimating tasks. The whole team should be involved in estimating the rough size of user stories though, if planning poker is being used. Its
          Message 4 of 11 , Jun 14, 2013
          • 0 Attachment

            Hi, don't bother estimating tasks. The whole team should be involved in estimating the rough size of user stories though, if planning poker is being used. Its especially important that the whole team be involved when there are differences in understanding because the true purpose in estimating isn't the estimate it is to get the team to talk and transfer information.

            The word costing is interesting. Are you using a price per story point model?

            And remember it is the feature/requirement/problem as the customer understands it you are estimating and not the technical solution.

            On Jun 14, 2013 5:07 PM, "curiouschimp" <bhy@...> wrote:
             

            Hi all.

            I'd like some feedback on user story and task size estimation.

            Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

            Or those who are 'interested'?

            I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

            I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.

          • George Dinwiddie
            Hi, Curious Chimp, ... Have you thought about whether you really need to estimate the stories at all? If you re trying to pick the appropriate amount of work
            Message 5 of 11 , Jun 14, 2013
            • 0 Attachment
              Hi, Curious Chimp,

              On 6/14/13 11:07 AM, curiouschimp wrote:
              > Hi all.
              >
              > I'd like some feedback on user story and task size estimation.
              >
              > Is there a 'best practice' in using planning poker? Do you use all
              > the engineers or a subset with domain expertise who will most likely
              > be taking on the tasks?
              >
              > Or those who are 'interested'?
              >
              > I know that ideally, engineers should be full stack but the team has
              > certain expertise they've taken ownership of.
              >
              > I've done reading and I have my own conclusion but I'm interested in
              > hearing more. There is a thought among the team to let an 'interested
              > party' group do the costing, rather than the whole dev team.

              Have you thought about whether you really need to estimate the stories
              at all? If you're trying to pick the appropriate amount of work for the
              next sprint, you may find that just counting the stories is sufficient.
              At least, that's been my experience.

              Another approach: list the acceptance scenarios necessary to be sure the
              story is working correctly. Use the number of scenarios as your
              estimate. The list of scenarios is valuable for a number of other
              reasons. Therefore you get your estimate for free. You can also split a
              story by bundles of scenarios.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Charles Bradley - Professional Scrum Trai
              ... (going off topic a bit from the OP s question) I m not a big fan of such approaches(another similar one is called white elephant sizing) because, IMO, it
              Message 6 of 11 , Jun 14, 2013
              • 0 Attachment
                > huge fan of the Planning Game

                (going off topic a bit from the OP's question)

                I'm not a big fan of such approaches(another similar one is called white elephant sizing) because, IMO, it limits conversations, interactions, and it takes to long because it is single threaded.  It probably works fine in certain circumstances (small number of stories, smaller teams who can have a quick conversations and then move on without the need for more discussion, conversations not as necessary?, people need a break from the usual technique,  etc )

                When there is a fairly small number of stories, I much prefer efficient backlog grooming sessions with planning poker.

                To scale to a large number of stories, I much prefer Lee Henson's Rapid Release Planning over the "put it on the wall/table approaches".  RRP encourages individuals and interactions, teamwork, and collaboration, while allowing for "parallel processing" efficiencies. It also uses time-boxes, which help keep the process efficient:
                http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf
                (The main RRP technique is described in the last few pages)

                I coach a similar "team collaboration, parallel processing" strategy for DoD workshops and retrospectives sometimes.  Don't get me wrong, I coach and teach a variety of techniques, but I certainly do skew towards certain Scrum patterns when the context is appropriate.
                 
                -------
                Charles Bradley
                Professional Scrum Trainer
                Scrum Coach-in-Chief
                ScrumCrazy.com




                From: Kevin Callahan <kcallahan@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Friday, June 14, 2013 9:27 AM
                Subject: Re: [scrumdevelopment] User story estimation



                I'm a huge fan of the Planning Game, which I learned from Chris Sims @ Agile Learning Labs. They have a post about it here:


                This doesn't help at all with prioritization, though you could probably do a similar activity with stakeholders assigning a business value estimate to each story and get a force-ranking of priorities.

                I'm also not entirely sure how these slice against story mapping, which I understand more to be a visualization/exploration of the work required for specific features (and might be a thread hijack, so please point that out if it's true). Though I'd be very interested to hear thoughts on that as well...

                -k

                On Jun 14, 2013, at 11:07 AM, curiouschimp wrote:

                 
                Hi all.

                I'd like some feedback on user story and task size estimation.

                Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

                Or those who are 'interested'?

                I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

                I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.


                Kevin Callahan
                Scrum Master & Agile Coach
                LiveWorld Inc.

                Mobile+1 (207) 691-2997
                Emailkcallahan@...
                Skypekevmocal
                Webwww.liveworld.com

                Follow UsFacebook Twitter LinkedIn







              • Charles Bradley - Professional Scrum Trai
                Below are some good responses from Steve and Jesse, I so I will +1 and add a couple of comments ... In Scrum, we shy away from titles -- so the real question
                Message 7 of 11 , Jun 14, 2013
                • 0 Attachment
                  Below are some good responses from Steve and Jesse, I so I will +1 and add a couple of comments

                  > Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

                  In Scrum, we shy away from "titles" -- so the real question is -- who estimates on a Scrum team?  The answer is that anyone can estimate on the Scrum Team, but the Dev Team has the last say on estimates, which means the Dev Team self organizes to decide how they express that "last say".  A big part of self organization is that the Dev Team *creates AND executes their own plan.*  IME coaching teams,  planning poker seems to work the best for estimation, and the vast majority of the time, the entire Dev Team (Dev Team role as described by the Scrum Guide) estimates, and no one else generally estimates.

                  > There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.
                   
                  This is a hard statement for me to parse.  Estimating is not "costing" (at least not exactly), and who is this "interested party group" you speak of?  Are all members of the interested party group part of the Scrum team?  If this interested party group is not comprised of Scrum team members, then why does the team want to let them estimate?

                  Note that, since we're on a Scrum list, I'm assuming you're doing Scrum -- but maybe you're not.  If you're not doing Scrum, that would be helpful to know.

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




                  From: Jesse Houwing <jesse.houwing@...>
                  To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
                  Sent: Friday, June 14, 2013 10:32 AM
                  Subject: Re: [scrumdevelopment] User story estimation



                  I hear you mention two separate things, task size estimation and userstory estimation. 

                  For the story part, prefer the whole team, even though the 'domain expert' might think he knows everything it's good to have input from others to challenge the number. It also prevents people from guesstimating too low numbers, since they already know so much. Or people from forgetting the amount of work the updating of the automated tests, the test data or the deployment scripts is going to take :).

                  For tasks you'd still prefer the whole team, but when there is a clear indication on who will do the task (which could be a small, domain bound step in the story) then the 'domain expert' usually has more weight, especially when he comes up with a higher number. We don't usually do planning poker for tasks, since it's, in our case, an estimate in hours and not relative to another task as with user stories. You can do this when your tasks are small enough to be completed in about one day. Usually when a developer or a pair of developers picks up the task, they revisit the original estimation to make sure it's still valid, then update their progress at the end of the day (which usually means they close out the task). The most important thing we agree on as a team is that the story is small enough to be executed in one or two days.


                  On Fri, Jun 14, 2013 at 5:26 PM, <steveropa@...> wrote:


                  I really try to get dissolve the idea of domain expertise as quickly as possible.  One way to do that is to ensure that the entire team(not just the engineers) are part of the estimation process.  By allowing the “interested party” approach, you are helping your engineers create silos.  Not only that but you are enabling self destructive behavior as far as their own careers go. 
                   
                  One thing I really like to stress for those engineers is that each story is a team commitment, even if they expect to be separating into their usual silos.  If nothing else, by estimating together, they can help other team members understand why they think their stories are the size they are...
                   
                  Steve
                   
                  Sent from Windows Mail
                   
                  From: curiouschimp
                  Sent: ‎Friday‎, ‎June‎ ‎14‎, ‎2013 ‎9‎:‎07‎ ‎AM
                  To: scrumdevelopment@yahoogroups.com
                   
                   
                  Hi all.

                  I'd like some feedback on user story and task size estimation.

                  Is there a 'best practice' in using planning poker? Do you use all the engineers or a subset with domain expertise who will most likely be taking on the tasks?

                  Or those who are 'interested'?

                  I know that ideally, engineers should be full stack but the team has certain expertise they've taken ownership of.

                  I've done reading and I have my own conclusion but I'm interested in hearing more. There is a thought among the team to let an 'interested party' group do the costing, rather than the whole dev team.








                • Ron Jeffries
                  Charles, ... Can t say I m very fond of that slide set. It seems to be a melange of every idea in Agile Planning, with a little something for everyone. One
                  Message 8 of 11 , Jun 14, 2013
                  • 0 Attachment
                    Charles,

                    On Jun 14, 2013, at 6:25 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:

                    To scale to a large number of stories, I much prefer Lee Henson's Rapid Release Planning over the "put it on the wall/table approaches".  RRP encourages individuals and interactions, teamwork, and collaboration, while allowing for "parallel processing" efficiencies. It also uses time-boxes, which help keep the process efficient:
                    http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf 
                    (The main RRP technique is described in the last few pages)

                    Can't say I'm very fond of that slide set. It seems to be a melange of every idea in Agile Planning, with a little something for everyone.

                    One Particularly Bad Idea is the notion of mixing Must Have, Should Have, Could Have and Would Like into each Sprint.

                    That strategy is demonstrably inferior to doing all the important things first. Its sole advantage(?) is that if you happen not to get something done you can say "well, we didn't really want it that badly anyway". Arrgh.

                    The notion of the PO (cloud(!)) estimating things is also … questionable. It seems he's using it to identify things that the team does not understand. That's a good thing to accomplish, but I don't see why the PO estimating development time is a useful way to do that. To make it fair, can the developers express their expectations for feature revenue? :)

                    Ron Jeffries
                    I know we always like to say it'll be easier to do it now than it
                    will be to do it later. Not likely. I plan to be smarter later than
                    I am now, so I think it'll be just as easy later, maybe even easier.
                    Why pay now when we can pay later?

                  • Charles Bradley - Professional Scrum Trai
                    Ron, All good points as usual. I m glad you brought it up because I should have given a more clear disclaimer that the RRP technique is essentially described
                    Message 9 of 11 , Jun 15, 2013
                    • 0 Attachment
                      Ron,

                      All good points as usual. I'm glad you brought it up because I should have given a more clear "disclaimer" that the RRP technique is essentially described in the last handful of slides, and that the rest of the slides might be viewed as controversial or outdated, so I'm claiming nothing one way or the other about those slides.  In addition, you have to remember that this is a presentation slide deck, so we're probably missing quite a bit of the context (I've been to the preso twice, so I have the more full context, but I also don't remember every last detail.)

                      > . It seems he's using it to identify things that the team does not understand.
                      Yes, and... things where there is simply a large disconnect(estimate difference = more than one t-shirt size apart) between the PO and Dev Team.  As I understood it, one of the main "disconnects" we're looking for there is something that the PO thinks is much easier to implement than it really is, and thus significantly affecting the ROI equation of value/cost.  He's very careful to make sure that the PO estimates do not skew the Dev Team estimates.  He refers to these large disconnects as anomolies, and lets a bit more discussion happen about each of them.  He then rightly says that the Dev Team gets the last say on the estimate after the "anomaly" discussion. 

                      IIRC, the first time I heard the preso, I was one of the people that encouraged him to make that "PO skewing risk" clearer and less likely to happen. 

                      > To make it fair, can the developers express their expectations for feature revenue? :)
                      Wow... that's an interesting point... and would be a very interesting exercise... seeing as how you could make the argument, in contexts where the Dev Team has a lot of domain knowledge, that the "anomalies" there should be discussed too!  In that case, of course, the PO has the last say.

                      One other disclaimer... let's remember that this is a "Release Planning" technique, not a Backlog Grooming/Refinement technique.  One would still do normal grooming on every story. 

                      I also want to make it clear that, IME, the RRP as described, is really most useful(sweet spot) for the multiple teams/one product/co-located teams/lots of backlog items context.  I have also successfully scaled/modified the RRP techniques down to a single large team(7-9 devs) with a couple of remote members(video conferencing).  I'm not convinced one would ever need RRP with a smaller team with less (possibly larger) backlog items to work with in a Release Planning session.  You could probably just use good ol' planning poker for those situations.  So, while I've tried the "white elephant sizing" and similar concepts before, IME, they are generally much less efficient and effective than the other techniques mentioned in this paragraph.  They are sometimes more fun, but not as efficient and effective in my view.

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




                      From: Ron Jeffries <ronjeffries@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Friday, June 14, 2013 5:27 PM
                      Subject: Re: [scrumdevelopment] User story estimation



                      Charles,

                      On Jun 14, 2013, at 6:25 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:

                      To scale to a large number of stories, I much prefer Lee Henson's Rapid Release Planning over the "put it on the wall/table approaches".  RRP encourages individuals and interactions, teamwork, and collaboration, while allowing for "parallel processing" efficiencies. It also uses time-boxes, which help keep the process efficient:
                      http://milehighagile.files.wordpress.com/2011/04/rapidreleaseplanning.pdf 
                      (The main RRP technique is described in the last few pages)

                      Can't say I'm very fond of that slide set. It seems to be a melange of every idea in Agile Planning, with a little something for everyone.

                      One Particularly Bad Idea is the notion of mixing Must Have, Should Have, Could Have and Would Like into each Sprint.

                      That strategy is demonstrably inferior to doing all the important things first. Its sole advantage(?) is that if you happen not to get something done you can say "well, we didn't really want it that badly anyway". Arrgh.

                      The notion of the PO (cloud(!)) estimating things is also … questionable. It seems he's using it to identify things that the team does not understand. That's a good thing to accomplish, but I don't see why the PO estimating development time is a useful way to do that. To make it fair, can the developers express their expectations for feature revenue? :)

                      Ron Jeffries
                      I know we always like to say it'll be easier to do it now than it
                      will be to do it later. Not likely. I plan to be smarter later than
                      I am now, so I think it'll be just as easy later, maybe even easier.
                      Why pay now when we can pay later?





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