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

Estimates changing drastically during the iteration

Expand Messages
  • Andrew Wagner
    Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were
    Message 1 of 17 , Sep 2, 2009
      Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were way off. Thus, we have to get together and re-determine what stories we can actually get done during the iteration, and what we can't, including meeting with the PO to get a "priorities" perspective. Note that this isn't a change like "oh, and we need this added to the feature too", but "oh crap, we can't do this this way on our architecture, we have to do it this completely different way". Is this normal? How can it be mitigated? The PO asked us yesterday how he's supposed to trust our estimates, and, frankly, I thought it was a very valid question.
    • Frank Rios
      Andrew, I m not sure if you re doing this already or not, but what if you broke out the story into two parts: one for architecture/analysis, and another for
      Message 2 of 17 , Sep 2, 2009
        Andrew,

        I'm not sure if you're doing this already or not, but what if you broke out the story into two parts: one for architecture/analysis, and another for feature development based on architecture?

        The idea behind this is it's easier to modify a model than code.

        --Frank


        From: Andrew Wagner <wagner.andrew@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wednesday, September 2, 2009 12:44:11 PM
        Subject: [scrumdevelopment] Estimates changing drastically during the iteration

         

        Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were way off. Thus, we have to get together and re-determine what stories we can actually get done during the iteration, and what we can't, including meeting with the PO to get a "priorities" perspective. Note that this isn't a change like "oh, and we need this added to the feature too", but "oh crap, we can't do this this way on our architecture, we have to do it this completely different way". Is this normal? How can it be mitigated? The PO asked us yesterday how he's supposed to trust our estimates, and, frankly, I thought it was a very valid question.


      • Andrew Wagner
        You mean as two tasks within the same story? Yes, we do that. However, the estimate for the implementation part tends to change dramatically when we do the
        Message 3 of 17 , Sep 2, 2009
          You mean as two tasks within the same story? Yes, we do that. However, the estimate for the implementation part tends to change dramatically when we do the analysis part. And we don't want to break it into multiple stories because it's not much of a "user story" to design something...I mean, how would you acceptance-test it?

          On Wed, Sep 2, 2009 at 2:15 PM, Frank Rios <sleepinggnome@...> wrote:
           

          Andrew,

          I'm not sure if you're doing this already or not, but what if you broke out the story into two parts: one for architecture/analysis, and another for feature development based on architecture?

          The idea behind this is it's easier to modify a model than code.

          --Frank


          From: Andrew Wagner <wagner.andrew@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Wednesday, September 2, 2009 12:44:11 PM
          Subject: [scrumdevelopment] Estimates changing drastically during the iteration

           

          Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were way off. Thus, we have to get together and re-determine what stories we can actually get done during the iteration, and what we can't, including meeting with the PO to get a "priorities" perspective. Note that this isn't a change like "oh, and we need this added to the feature too", but "oh crap, we can't do this this way on our architecture, we have to do it this completely different way". Is this normal? How can it be mitigated? The PO asked us yesterday how he's supposed to trust our estimates, and, frankly, I thought it was a very valid question.



        • George Dinwiddie
          ... But easier to verigy code than a model. I would suggest splitting a thin but functional sliver that drives through the architectural layers. This should
          Message 4 of 17 , Sep 2, 2009
            Frank Rios wrote:
            >
            >
            > Andrew,
            >
            > I'm not sure if you're doing this already or not, but what if you broke
            > out the story into two parts: one for architecture/analysis, and another
            > for feature development based on architecture?
            >
            > The idea behind this is it's easier to modify a model than code.

            But easier to verigy code than a model. I would suggest splitting a
            thin but functional sliver that drives through the architectural layers.
            This should handle a simplistic case, but "fire a tracer bullet"
            through the application.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Dan LeFebvre
            Andrew, Have you asked the team? They may have a better insight into why this is happening. Are they having design discussions during the Sprint Planning
            Message 5 of 17 , Sep 2, 2009

              Andrew,

               

              Have you asked the team? They may have a better insight into why this is happening. Are they having design discussions during the Sprint Planning meeting? Maybe they need to do this a little more. Are they lacking architectural knowledge? Maybe spending time with some who does would help. Or maybe having that person join the team.

               

              It is difficult to suggest mitigation strategies without knowing the whole story. Your team should know the whole story; so again, ask the team.

               

              Regards,

               

              Dan LeFebvre

               

               

              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Andrew Wagner
              Sent: Wednesday, September 02, 2009 1:44 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Estimates changing drastically during the iteration

               



              Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were way off. Thus, we have to get together and re-determine what stories we can actually get done during the iteration, and what we can't, including meeting with the PO to get a "priorities" perspective. Note that this isn't a change like "oh, and we need this added to the feature too", but "oh crap, we can't do this this way on our architecture, we have to do it this completely different way". Is this normal? How can it be mitigated? The PO asked us yesterday how he's supposed to trust our estimates, and, frankly, I thought it was a very valid question.


            • Andrew Wagner
              I m on the team, so I have a pretty good idea what s going on. We re not talking about design in our planning meetings as they re already several hours long at
              Message 6 of 17 , Sep 2, 2009
                I'm on the team, so I have a pretty good idea what's going on. We're not talking about design in our planning meetings as they're already several hours long at a time.

                Sent from my iPhone

                On Sep 2, 2009, at 3:35 PM, "Dan LeFebvre" <d-lefebvre@...> wrote:

                 

                Andrew,

                 

                Have you asked the team? They may have a better insight into why this is happening. Are they having design discussions during the Sprint Planning meeting? Maybe they need to do this a little more. Are they lacking architectural knowledge? Maybe spending time with some who does would help. Or maybe having that person join the team.

                 

                It is difficult to suggest mitigation strategies without knowing the whole story. Your team should know the whole story; so again, ask the team.

                 

                Regards,

                 

                Dan LeFebvre

                 

                 

                From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Andrew Wagner
                Sent: Wednesday, September 02, 2009 1:44 PM
                To: scrumdevelopment@ yahoogroups. com
                Subject: [scrumdevelopment] Estimates changing drastically during the iteration

                 



                Our team is finding that when we go to actually implement a piece of functionality, sometimes we realize that our estimates during the planning meeting were way off. Thus, we have to get together and re-determine what stories we can actually get done during the iteration, and what we can't, including meeting with the PO to get a "priorities" perspective. Note that this isn't a change like "oh, and we need this added to the feature too", but "oh crap, we can't do this this way on our architecture, we have to do it this completely different way". Is this normal? How can it be mitigated? The PO asked us yesterday how he's supposed to trust our estimates, and, frankly, I thought it was a very valid question.


              • Ron Jeffries
                Hello, Andrew. On Wednesday, September 2, 2009, at 1:44:11 PM, ... Perhaps your stories are too big? Do you do a quick design discussion before commitment?
                Message 7 of 17 , Sep 2, 2009
                  Hello, Andrew. On Wednesday, September 2, 2009, at 1:44:11 PM,
                  you wrote:

                  > Our team is finding that when we go to actually implement a piece of
                  > functionality, sometimes we realize that our estimates during the planning
                  > meeting were way off. Thus, we have to get together and re-determine what
                  > stories we can actually get done during the iteration, and what we can't,
                  > including meeting with the PO to get a "priorities" perspective. Note that
                  > this isn't a change like "oh, and we need this added to the feature too",
                  > but "oh crap, we can't do this this way on our architecture, we have to do
                  > it this completely different way". Is this normal? How can it be mitigated?

                  Perhaps your stories are too big?

                  Do you do a quick design discussion before commitment?

                  > The PO asked us yesterday how he's supposed to trust our estimates, and,
                  > frankly, I thought it was a very valid question.

                  He's supposed to trust your velocity.

                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  The central "e" in "Jeffries" is silent ... and invisible.
                • Ron Jeffries
                  Hello, Andrew. On Wednesday, September 2, 2009, at 4:01:10 PM, ... Two questions: Why are they several hours long? How do you imagine you could get good
                  Message 8 of 17 , Sep 2, 2009
                    Hello, Andrew. On Wednesday, September 2, 2009, at 4:01:10 PM,
                    you wrote:

                    > I'm on the team, so I have a pretty good idea what's going on. We're
                    > not talking about design in our planning meetings as they're already
                    > several hours long at a time.

                    Two questions:

                    Why are they several hours long?

                    How do you imagine you could get good estimates without
                    understanding the design impact of the story?

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    Sorry about your cow ... I didn't know she was sacred.
                  • jmilunsky
                    This sort of thing is precisely why i like to do task breakdown during the 2nd half of the sprint planning meeting. (most of the xp guru s don t encourage this
                    Message 9 of 17 , Sep 3, 2009
                      This sort of thing is precisely why i like to do task breakdown during the 2nd half of the sprint planning meeting. (most of the xp guru's don't encourage this step and prefer to rather keep things at the story level). But my experience shows that this helps.

                      yes this is normal especially if you didn't do enough thinking about the story up front. You have to really get enough conversation going about the story with the customer or the PO

                      Jack
                      www.agilebuddy.com
                      blog.agilebuddy.com
                      twitter.com/agilebuddy



                      --- In scrumdevelopment@yahoogroups.com, Andrew Wagner <wagner.andrew@...> wrote:
                      >
                      > Our team is finding that when we go to actually implement a piece of
                      > functionality, sometimes we realize that our estimates during the planning
                      > meeting were way off. Thus, we have to get together and re-determine what
                      > stories we can actually get done during the iteration, and what we can't,
                      > including meeting with the PO to get a "priorities" perspective. Note that
                      > this isn't a change like "oh, and we need this added to the feature too",
                      > but "oh crap, we can't do this this way on our architecture, we have to do
                      > it this completely different way". Is this normal? How can it be mitigated?
                      > The PO asked us yesterday how he's supposed to trust our estimates, and,
                      > frankly, I thought it was a very valid question.
                      >
                    • Ron Jeffries
                      Hello, jmilunsky. On Thursday, September 3, 2009, at 11:57:01 AM, ... See Quick Design Session , XP Installed. What I don t like is /scheduling tasks/. I
                      Message 10 of 17 , Sep 3, 2009
                        Hello, jmilunsky. On Thursday, September 3, 2009, at 11:57:01 AM,
                        you wrote:

                        > This sort of thing is precisely why i like to do task breakdown
                        > during the 2nd half of the sprint planning meeting. (most of the
                        > xp guru's don't encourage this step and prefer to rather keep
                        > things at the story level). But my experience shows that this helps.

                        See "Quick Design Session", XP Installed.

                        What I don't like is /scheduling tasks/. I think they should be
                        discussed and then the /story/ should be scheduled.

                        Ron Jeffries
                        www.XProgramming.com
                        www.xprogramming.com/blog
                        A man hears what he wants to hear, and disregards the rest. -- Paul Simon
                      • Adrian Howard
                        ... I see that sort of thing in two sorts of situations: 1) The stories are too big (days to weeks, rather than hours to days) 2) There s an existing legacy
                        Message 11 of 17 , Sep 3, 2009
                          On 2 Sep 2009, at 18:44, Andrew Wagner wrote:

                          > Our team is finding that when we go to actually implement a piece of
                          > functionality, sometimes we realize that our estimates during the
                          > planning
                          > meeting were way off. Thus, we have to get together and re-determine
                          > what
                          > stories we can actually get done during the iteration, and what we
                          > can't,
                          > including meeting with the PO to get a "priorities" perspective.
                          > Note that
                          > this isn't a change like "oh, and we need this added to the feature
                          > too",
                          > but "oh crap, we can't do this this way on our architecture, we have
                          > to do
                          > it this completely different way". Is this normal? How can it be
                          > mitigated?

                          I see that sort of thing in two sorts of situations:
                          1) The stories are too big (days to weeks, rather than hours to days)
                          2) There's an existing legacy ball of mud which is hard for the team
                          to grok

                          Do either of these sound like likely causes?

                          Solution to (1) - smaller stories :-)

                          I occasionally that (2) is due to nobody understanding how everything
                          works. Person X knows system A, person Y knows subsystem B, nobody
                          really understands how A and B work together. Things like promiscuous
                          pairing can help spread that knowledge around.

                          Cheers,

                          Adrian
                          --
                          http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                        • Andrew Wagner
                          ... Yes, just a quick one. ... Yeah, but we re always changing what we tell him we can get done in that velocity, which is why I feel untrustworthy.
                          Message 12 of 17 , Sep 4, 2009

                            Perhaps your stories are too big?

                            Possible. They're not usually more than a couple of days though.
                             
                             


                             
                            Do you do a quick design discussion before commitment?



                            Yes, just a quick one.
                             

                            > The PO asked us yesterday how he's supposed to trust our estimates, and,
                            > frankly, I thought it was a very valid question.

                            He's supposed to trust your velocity.







                            Yeah, but we're always changing what we tell him we can get done in that velocity, which is why I feel untrustworthy.
                             
                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            The central "e" in "Jeffries" is silent ... and invisible.


                          • Andrew Wagner
                            ... There are typically two planning meetings for each iteration (at least for the two that we ve done so far): - In the first, we get an understanding of the
                            Message 13 of 17 , Sep 4, 2009
                              Why are they several hours long?



                              There are typically two planning meetings for each iteration (at least for the two that we've done so far):
                                - In the first, we get an understanding of the story, and do a high-level (planning-poker-based) story estimate. In this, we try to avoid talking about implementation details completely, because it feels like the wrong level of abstraction.
                                - In the second, we break the story estimate into tasks, divvy out the tasks, and whoever gets the task provides their estimate.

                              Both just tend to take several hours, I'm not sure how to answer "why". Note that we are still (at this point) estimating in terms of hours, not points.
                               
                              How do you imagine you could get good estimates without
                              understanding the design impact of the story?



                              Agreed, and we do try to quickly get a grasp of the design when doing our task-level estimates, but it seems like when we sit down to actually do the work, other things come up and things spin out of control. Part of this, too, is that it seems like any work that we do in estimating the work before we actually commit to doing it in an iteration is a liability, isn't it?
                               
                              Sorry about your cow ... I didn't know she was sacred.


                            • Andrew Wagner
                              Dude, are you spying on us?? :)
                              Message 14 of 17 , Sep 4, 2009
                                Dude, are you spying on us?? :)

                                On Thu, Sep 3, 2009 at 1:34 PM, Adrian Howard <adrianh@...> wrote:
                                 


                                On 2 Sep 2009, at 18:44, Andrew Wagner wrote:

                                > Our team is finding that when we go to actually implement a piece of
                                > functionality, sometimes we realize that our estimates during the
                                > planning
                                > meeting were way off. Thus, we have to get together and re-determine
                                > what
                                > stories we can actually get done during the iteration, and what we
                                > can't,
                                > including meeting with the PO to get a "priorities" perspective.
                                > Note that
                                > this isn't a change like "oh, and we need this added to the feature
                                > too",
                                > but "oh crap, we can't do this this way on our architecture, we have
                                > to do
                                > it this completely different way". Is this normal? How can it be
                                > mitigated?

                                I see that sort of thing in two sorts of situations:
                                1) The stories are too big (days to weeks, rather than hours to days)
                                2) There's an existing legacy ball of mud which is hard for the team
                                to grok

                                Do either of these sound like likely causes?

                                Solution to (1) - smaller stories :-)

                                I occasionally that (2) is due to nobody understanding how everything
                                works. Person X knows system A, person Y knows subsystem B, nobody
                                really understands how A and B work together. Things like promiscuous
                                pairing can help spread that knowledge around.

                                Cheers,

                                Adrian
                                --
                                http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh


                              • sschuermann303
                                Hi This explains a lot. If youre using planning 1 for estimation, youre doomed. There are several mistakes in this behaviour (my point of view) ... for ...
                                Message 15 of 17 , Sep 4, 2009
                                  Hi


                                  This explains a lot. If youre using planning 1 for estimation, youre
                                  doomed. There are several mistakes in this behaviour (my point of view)

                                  --- In scrumdevelopment@yahoogroups.com, Andrew Wagner
                                  <wagner.andrew@...> wrote:
                                  >
                                  > >
                                  > > Why are they several hours long?
                                  > >
                                  > >
                                  >
                                  > There are typically two planning meetings for each iteration (at least
                                  for
                                  > the two that we've done so far):
                                  > - In the first, we get an understanding of the story, and do a
                                  high-level
                                  > (planning-poker-based) story estimate. In this, we try to avoid
                                  talking
                                  > about implementation details completely, because it feels like the
                                  wrong
                                  > level of abstraction.

                                  1. You're wasting time. The reason of this meeting is gettingcommitment,
                                  not estimates. Just execute weekly estimation meetings ofone hour and
                                  use THIS for first discussions. We had several magicmoments where big
                                  tasks got small and small tasks grew big after we discussed the things
                                  while estimating them. Estimating is a very hard work, most times people
                                  are 100% wasted after 30 Minutes.

                                  2. You are doing the wrong thing. The only sense of planning I (as
                                  weexecute it) is to commit to some sort of result (how to reach
                                  thesprint goal) and determine factors that define if something is done.

                                  3. The estimation meetings are filled with a lot of discussions. How
                                  should different persons come to an close estimate? We have
                                  juniorprogrammers and seniors in the same meeting. Totally different
                                  skillset, totally different point of views. But we stop estimating a
                                  task only if we can find a estimation that is agreed on by everybody.
                                  This means some estimation meetings only estimate one or two features
                                  only.
                                  I guess your stategy of letting one person work on a task is not helping
                                  good estimates either.

                                  > - In the second, we break the story estimate into tasks, divvy out
                                  the
                                  > tasks, and whoever gets the task provides their estimate.


                                  4. Re-Estimating in Planning II, please NOT.
                                  Focus should be on the details of implementation in terms of what kind
                                  of steps have to be taken (right). You do not know who will work on a
                                  task, remember, its pull, not push. Better work with 2 people, or 3 on
                                  one task/subtask. It might seem as a waste of time. When you reach
                                  sprint 10 you will see how the "magic" works. More people know how
                                  things work, more piece of cake tasks arise, estimates get closer. All
                                  gets easier.

                                  >
                                  > Both just tend to take several hours, I'm not sure how to answer
                                  "why". Note
                                  > that we are still (at this point) estimating in terms of hours, not
                                  points.

                                  This could be a main reason of the described problems. Estimating in
                                  hours makes people defensive because hours don't abstract from
                                  sideeffects that arise in each sprint: people get ill, servers get
                                  kernel panics, temperatures rise above 30 degrees celsius,
                                  relationsships break up ... etc. life happens!

                                  Following standard example explains a lot more what I am pointing out
                                  to:

                                  Estimate travelling from Amsterdam/Holland to New York/Usa. It's easy to
                                  estimate how far both places are away from each other: Several Thousand
                                  Kilometers. It's harder to estimate how long you will need to reach NY,
                                  depending on how you travel. Using a ship, Using a plane?
                                  Senior programmer vs. Junior Programmer?

                                  > > How do you imagine you could get good estimates without
                                  > > understanding the design impact of the story?
                                  > >
                                  Never, if you estimate Time. If you estimate size, very easy because
                                  design plays a lesser role.
                                  >
                                  > Agreed, and we do try to quickly get a grasp of the design when doing
                                  our
                                  > task-level estimates, but it seems like when we sit down to actually
                                  do the
                                  > work, other things come up and things spin out of control. Part of
                                  this,
                                  > too, is that it seems like any work that we do in estimating the work
                                  before
                                  > we actually commit to doing it in an iteration is a liability, isn't
                                  it?

                                  We only estimate features, never the tasks at hand to finish a feature.
                                  As long as you do not know the capacity of your team (Storypoints per
                                  Iteration the ycan get done), commiting always is a liabillity.
                                  But this will never fade away as long as you estimate hrs and not SP.
                                  The SP estimates are for removing the liability.

                                  Sebastian
                                • Adrian Howard
                                  ... I prefer to call it research :) Adrian -- http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                                  Message 16 of 17 , Sep 4, 2009
                                    On 4 Sep 2009, at 14:00, Andrew Wagner wrote:

                                    > Dude, are you spying on us?? :)

                                    I prefer to call it "research" :)

                                    Adrian

                                    --
                                    http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                                  • sschuermann303
                                    ... planning ... what ... can t, One big thing on Scrum is: There is peace while the sprint is in progress. No re-estimates. No Changes of priority. Let the
                                    Message 17 of 17 , Sep 4, 2009
                                      --- In scrumdevelopment@yahoogroups.com, Andrew Wagner
                                      <wagner.andrew@...> wrote:
                                      >
                                      > Our team is finding that when we go to actually implement a piece of
                                      > functionality, sometimes we realize that our estimates during the
                                      planning
                                      > meeting were way off. Thus, we have to get together and re-determine
                                      what
                                      > stories we can actually get done during the iteration, and what we
                                      can't,

                                      One big thing on Scrum is: There is peace while the sprint is in
                                      progress. No re-estimates.
                                      No Changes of priority. Let the people work. There is chance of inspect
                                      and adapt on the END
                                      of the sprint.

                                      > including meeting with the PO to get a "priorities" perspective. Note
                                      that
                                      > this isn't a change like "oh, and we need this added to the feature
                                      too",
                                      > but "oh crap, we can't do this this way on our architecture, we have
                                      to do
                                      > it this completely different way". Is this normal? How can it be
                                      mitigated?
                                      > The PO asked us yesterday how he's supposed to trust our estimates,
                                      and,
                                      > frankly, I thought it was a very valid question.

                                      If you feel the need for work on the ongoing sprint, lets face it and
                                      finish the sprint, clean with
                                      review and retrospective. Deploy, get a day where you do new estimates
                                      and go.
                                      There is NO reason for re-estimating during a sprint, the question is:
                                      Are the developers getting the
                                      things done they commited to.
                                      Why he is supposed to trust the estimates? Because you guys are the
                                      programmers, and if executed right,
                                      the estimations will be way better than the ones from anybody else in
                                      your organization.
                                      it's a programmers job and noone elses. Lack of trust from the PO is a
                                      problem. Lack of trust from you is
                                      (if youre the SM) is a crisis. Did everybody commit to the prime
                                      directive? Doesn't sound like the PO agreed
                                      to that one really.

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