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

Re: [scrumdevelopment] Estimates changing drastically during the iteration

Expand Messages
  • 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 1 of 17 , Sep 2 11:15 AM
    • 0 Attachment
      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 2 of 17 , Sep 2 11:59 AM
      • 0 Attachment
        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 3 of 17 , Sep 2 12:24 PM
        • 0 Attachment
          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 4 of 17 , Sep 2 12:35 PM
          • 0 Attachment

            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 5 of 17 , Sep 2 1:01 PM
            • 0 Attachment
              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 6 of 17 , Sep 2 1:33 PM
              • 0 Attachment
                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 7 of 17 , Sep 2 2:08 PM
                • 0 Attachment
                  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 8 of 17 , Sep 3 8:57 AM
                  • 0 Attachment
                    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 9 of 17 , Sep 3 9:15 AM
                    • 0 Attachment
                      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 10 of 17 , Sep 3 10:34 AM
                      • 0 Attachment
                        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 11 of 17 , Sep 4 5:50 AM
                        • 0 Attachment

                          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 12 of 17 , Sep 4 5:59 AM
                          • 0 Attachment
                            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 13 of 17 , Sep 4 6:00 AM
                            • 0 Attachment
                              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 14 of 17 , Sep 4 9:21 AM
                              • 0 Attachment
                                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 15 of 17 , Sep 4 9:32 AM
                                • 0 Attachment
                                  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 16 of 17 , Sep 4 9:45 AM
                                  • 0 Attachment
                                    --- 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.