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

Assumptions that bite back

Expand Messages
  • pctnmrk
    Some questions arose during a recent Retro...   How should we handle technical assumptions during planning? (eg. assuming a third party service is easily
    Message 1 of 12 , Mar 1, 2012
      Some questions arose during a recent Retro...
       
      How should we handle technical assumptions during planning?
      (eg. assuming a third party service is easily integrated with our own solution)
       
      How should we best deal with technical difficulties which blow up mid sprint?
      (eg. finding out the third party service isn't easily integrated)
       
      I'd be very interested know if other Agile teams have had experience with this, and I'd appreciate any suggestions or feedback.
    • RonJeffries
      ... When you assume ... Schedule a backlog item to find out the facts when you don t know something. ... Use your retrospective to devise better approaches
      Message 2 of 12 , Mar 1, 2012

        On Mar 1, 2012, at 10:51 AM, pctnmrk wrote:

        How should we handle technical assumptions during planning?
        (eg. assuming a third party service is easily integrated with our own solution)

        "When you assume ..."

        Schedule a backlog item to find out the facts when you don't know something.
         
        How should we best deal with technical difficulties which blow up mid sprint?
        (eg. finding out the third party service isn't easily integrated)

        Use your retrospective to devise better approaches next time. That's what it's for.
         
        I'd be very interested know if other Agile teams have had experience with this, and I'd  appreciate any suggestions or feedback.

        Yes. Probably all of them.
        Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

      • Flavius Stef
        Hi pctnmrk, Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the
        Message 3 of 12 , Mar 1, 2012
          Hi pctnmrk,

          Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the next sprint.

          Flavius

          On 03/01/2012 05:51 PM, pctnmrk wrote:
           

          Some questions arose during a recent Retro...
           
          How should we handle technical assumptions during planning?
          (eg. assuming a third party service is easily integrated with our own solution)
           
          How should we best deal with technical difficulties which blow up mid sprint?
          (eg. finding out the third party service isn't easily integrated)
           
          I'd be very interested know if other Agile teams have had experience with this, and I'd appreciate any suggestions or feedback.


        • Charles Bradley - Scrum Coach CSM PSM I
          + 1 to Flavius idea (Spike Story or Spike Task), but I also use Backlog Grooming (grooming next sprint s items during the current sprint) to help highlight
          Message 4 of 12 , Mar 1, 2012
            + 1 to Flavius' idea (Spike Story or Spike Task), but I also use Backlog Grooming (grooming next sprint's items during the current sprint) to help highlight these risks.  If you have a good BG practice, and the spike period (to assess tool viability/mitigate risk) is small enough, you don't need a backlog item for it -- it's just a task someone does in their spare moments in the sprints proceeding the one when the new tool is needed.  If the spike period is bigger, than I'd say to put a spike on the product backlog or the sprint backlog.
             
            -------
            Charles Bradley
            http://www.ScrumCrazy.com




            From: Flavius Stef <flavius_stef@...>
            To: scrumdevelopment@yahoogroups.com
            Sent: Thursday, March 1, 2012 9:15 AM
            Subject: Re: [scrumdevelopment] Assumptions that bite back



            Hi pctnmrk,

            Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the next sprint.

            Flavius

            On 03/01/2012 05:51 PM, pctnmrk wrote:
             
            Some questions arose during a recent Retro...
             
            How should we handle technical assumptions during planning?
            (eg. assuming a third party service is easily integrated with our own solution)
             
            How should we best deal with technical difficulties which blow up mid sprint?
            (eg. finding out the third party service isn't easily integrated)
             
            I'd be very interested know if other Agile teams have had experience with this, and I'd appreciate any suggestions or feedback.






          • Sean Corfield
            ... This approach has served us well. Sometimes the spike makes enough progress that the actual work item is small, sometimes the spike shows how hard the task
            Message 5 of 12 , Mar 1, 2012
              On Thu, Mar 1, 2012 at 8:15 AM, Flavius Stef <flavius_stef@...> wrote:

              Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the next sprint.


              This approach has served us well. Sometimes the spike makes enough progress that the actual work item is small, sometimes the spike shows how hard the task is going to be and we may need another spike in the next sprint before we can identify small enough stories to represent the actual work item in usable form for a sprint.

              I'm curious as to how much time folks tend to allow for large, complex spikes? We've occasionally put aside a person week (and come close to using all of that time to find out what we need to know) but most spikes for us are about a day, rarely more than two days.
              --
              Sean A Corfield -- (904) 302-SEAN
              An Architect's View -- http://corfield.org/
              World Singles, LLC. -- http://worldsingles.com/

              "Perfection is the enemy of the good."
              -- Gustave Flaubert, French realist novelist (1821-1880)
            • RonJeffries
              Hi Sean, ... There really shouldn t be large, complex spikes , IMO. I suppose once in a while one might be necessary, like if we had to configure a computer
              Message 6 of 12 , Mar 1, 2012
                Hi Sean,

                On Mar 1, 2012, at 5:03 PM, Sean Corfield wrote:

                I'm curious as to how much time folks tend to allow for large, complex spikes? We've occasionally put aside a person week (and come close to using all of that time to find out what we need to know) but most spikes for us are about a day, rarely more than two days.

                There really shouldn't be "large, complex spikes", IMO. I suppose once in a while one might be necessary, like if we had to configure a computer first or something, but a day or two should be the norm.

                Of course, a day or two (possibly three) is also the norm for a story, as I see it.

                Ron Jeffries
                www.XProgramming.com
                There's no word for accountability in Finnish. 
                Accountability is something that is left when responsibility has been subtracted. 
                --Pasi Sahlberg

              • Charles Bradley - Scrum Coach CSM PSM I
                Ergo, the size of spikes is proportional to the average story size, and the average story size should be kept as small as the team can possibly keep them, down
                Message 7 of 12 , Mar 1, 2012
                  Ergo, the size of spikes is proportional to the average story size, and the average story size should be kept as small as the team can possibly keep them, down to a lower bound of about a day or two.

                  Also, I often say that the number of spikes should generally be somewhere less than about 10% of stories, and probably quite a bit smaller than 10%.  (This is to head off people that think every story now requires a spike... or people who term a "requirements gathering effort" as a spike... neither of which is appropriate or correct.)
                   
                  -------
                  Charles Bradley
                  http://www.ScrumCrazy.com




                  From: RonJeffries <ronjeffries@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Thursday, March 1, 2012 3:11 PM
                  Subject: Re: [scrumdevelopment] Assumptions that bite back



                  Hi Sean,

                  On Mar 1, 2012, at 5:03 PM, Sean Corfield wrote:

                  I'm curious as to how much time folks tend to allow for large, complex spikes? We've occasionally put aside a person week (and come close to using all of that time to find out what we need to know) but most spikes for us are about a day, rarely more than two days.

                  There really shouldn't be "large, complex spikes", IMO. I suppose once in a while one might be necessary, like if we had to configure a computer first or something, but a day or two should be the norm.

                  Of course, a day or two (possibly three) is also the norm for a story, as I see it.

                  Ron Jeffries
                  www.XProgramming.com
                  There's no word for accountability in Finnish. 
                  Accountability is something that is left when responsibility has been subtracted. 
                  --Pasi Sahlberg





                • Sean Corfield
                  ... I agree they should be rare but I think there are _some_ situations where a large, complex spike is reasonable. As I said, most of our spikes are a day,
                  Message 8 of 12 , Mar 1, 2012
                    On Thu, Mar 1, 2012 at 2:11 PM, RonJeffries <ronjeffries@...> wrote:
                    There really shouldn't be "large, complex spikes", IMO. I suppose once in a while one might be necessary, like if we had to configure a computer first or something, but a day or two should be the norm.

                    I agree they should be rare but I think there are _some_ situations where a "large, complex spike" is reasonable. As I said, most of our spikes are a day, sometimes two, but recently we had to replace our geo location subsystem and needed to explore various 3rd party APIs and figure out how to wrap them to achieve what we needed. We time-boxed five days and it took about four. We were back to smaller stories on top of that work after that. I was just curious to hear of some specific real world spikes from folks that exceeded the one or two day size...?

                    Of course, a day or two (possibly three) is also the norm for a story, as I see it.

                    Agreed, and as Charles observed, spikes should be far less frequent than (regular) stories. I'd be surprised if we had more than one spike per fifty stories, but then we also try to keep our stories pretty small (a lot of our stories run about half a day) and we're in a well-understood space (now, for us, after working on this platform for a couple of years).
                    --
                    Sean A Corfield -- (904) 302-SEAN
                    An Architect's View -- http://corfield.org/
                    World Singles, LLC. -- http://worldsingles.com/

                    "Perfection is the enemy of the good."
                    -- Gustave Flaubert, French realist novelist (1821-1880)
                  • RonJeffries
                    Hi Sean, Sounds just fine to me! R ... Ron Jeffries www.XProgramming.com Everything that needs to be said has already been said. But since no one was
                    Message 9 of 12 , Mar 1, 2012
                      Hi Sean,
                      Sounds just fine to me!
                      R
                      On Mar 1, 2012, at 7:43 PM, Sean Corfield wrote:

                      On Thu, Mar 1, 2012 at 2:11 PM, RonJeffries <ronjeffries@...> wrote:
                      There really shouldn't be "large, complex spikes", IMO. I suppose once in a while one might be necessary, like if we had to configure a computer first or something, but a day or two should be the norm.

                      I agree they should be rare but I think there are _some_ situations where a "large, complex spike" is reasonable. As I said, most of our spikes are a day, sometimes two, but recently we had to replace our geo location subsystem and needed to explore various 3rd party APIs and figure out how to wrap them to achieve what we needed. We time-boxed five days and it took about four. We were back to smaller stories on top of that work after that. I was just curious to hear of some specific real world spikes from folks that exceeded the one or two day size...?

                      Of course, a day or two (possibly three) is also the norm for a story, as I see it.

                      Agreed, and as Charles observed, spikes should be far less frequent than (regular) stories. I'd be surprised if we had more than one spike per fifty stories, but then we also try to keep our stories pretty small (a lot of our stories run about half a day) and we're in a well-understood space (now, for us, after working on this platform for a couple of years).


                      Ron Jeffries
                      www.XProgramming.com
                      Everything that needs to be said has already been said.
                      But since no one was listening, everything must be said again. -- Andre Gide

                    • JackM
                      Here s what I have found, Often times teams have a large story and they can t break it down until they run the spike story. So the original story can be 20 or
                      Message 10 of 12 , Mar 1, 2012
                        Here's what I have found,

                        Often times teams have a large story and they can't break it down until they run the spike story. So the original story can be 20 or even 40 points. So a week spike is not bad either. We have run a few of those. Then after that we can typically break that 40 pointer down into more than couple of stories once we understand it all.

                        Hope this helps
                        Jack
                        www.agilebuddy.com

                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                        >
                        > Ergo, the size of spikes is proportional to the average story size, and the average story size should be kept as small as the team can possibly keep them, down to a lower bound of about a day or two.
                        >
                        > Also, I often say that the number of spikes should generally be somewhere less than about 10% of stories, and probably quite a bit smaller than 10%.  (This is to head off people that think every story now requires a spike... or people who term a "requirements gathering effort" as a spike... neither of which is appropriate or correct.)
                        >
                        >  
                        > -------
                        > Charles Bradley
                        > http://www.ScrumCrazy.com
                        >
                        >
                        >
                        >
                        >
                        > >________________________________
                        > > From: RonJeffries <ronjeffries@...>
                        > >To: scrumdevelopment@yahoogroups.com
                        > >Sent: Thursday, March 1, 2012 3:11 PM
                        > >Subject: Re: [scrumdevelopment] Assumptions that bite back
                        > >
                        > >
                        > >
                        > >
                        > >
                        > >Hi Sean,
                        > >
                        > >
                        > >On Mar 1, 2012, at 5:03 PM, Sean Corfield wrote:
                        > >
                        > >I'm curious as to how much time folks tend to allow for large, complex spikes? We've occasionally put aside a person week (and come close to using all of that time to find out what we need to know) but most spikes for us are about a day, rarely more than two days.
                        > >
                        > >There really shouldn't be "large, complex spikes", IMO. I suppose once in a while one might be necessary, like if we had to configure a computer first or something, but a day or two should be the norm.
                        > >
                        > >
                        > >Of course, a day or two (possibly three) is also the norm for a story, as I see it.
                        > >
                        > >
                        > >Ron Jeffrieswww.XProgramming.comThere's no word for accountability in Finnish. 
                        > >Accountability is something that is left when responsibility has been subtracted. 
                        > >--Pasi Sahlberg
                        > >
                        > >
                        > >
                        > >
                        > >
                        > >
                        >
                      • Charles Bradley - Scrum Coach CSM PSM I
                        Sean, The largest spike I ve seen was around a person week as well.  The team was moving from v50 to v75 of a 3rd party library when not a single developer on
                        Message 11 of 12 , Mar 1, 2012
                          Sean,

                          The largest spike I've seen was around a person week as well.  The team was moving from v50 to v75 of a 3rd party library when not a single developer on the team had been present when the previous integration happened, and very few of them had ever even enhanced code in that area.  The spike's method for reducing the follow on story risk was to do a gap analysis (field mappings, new errors, and new logic needed) for each of the api calls.  Like you, the rest of the spikes were 1-3 days.
                           
                          -------
                          Charles Bradley
                          http://www.ScrumCrazy.com




                          From: Sean Corfield <seancorfield@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Thursday, March 1, 2012 3:03 PM
                          Subject: Re: [scrumdevelopment] Assumptions that bite back



                          On Thu, Mar 1, 2012 at 8:15 AM, Flavius Stef <flavius_stef@...> wrote:
                          Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the next sprint.

                          This approach has served us well. Sometimes the spike makes enough progress that the actual work item is small, sometimes the spike shows how hard the task is going to be and we may need another spike in the next sprint before we can identify small enough stories to represent the actual work item in usable form for a sprint.

                          I'm curious as to how much time folks tend to allow for large, complex spikes? We've occasionally put aside a person week (and come close to using all of that time to find out what we need to know) but most spikes for us are about a day, rarely more than two days.
                          --
                          Sean A Corfield -- (904) 302-SEAN
                          An Architect's View -- http://corfield.org/
                          World Singles, LLC. -- http://worldsingles.com/

                          "Perfection is the enemy of the good."
                          -- Gustave Flaubert, French realist novelist (1821-1880)




                        • Flavius Stef
                          Charles, I agree. In fact, one story might illustrate your point. At one planning meeting (with no previous grooming), a team was analyzing a story which
                          Message 12 of 12 , Mar 2, 2012
                            Charles, I agree.

                            In fact, one story might illustrate your point. At one planning meeting (with no previous grooming), a team was analyzing a story which included an elaborate chart. None of them had experience with using charts in their framework (WPF), so they decided to allocate 5 days of research for it.

                            During the sprint, after about two hours of work, the developer in charge with the research triumphantly announced that he had figured out the way to make it work, thus leaving him with almost five "free" days.

                            Doing backlog grooming in this situation would have helped a lot in planning.

                            Flavius

                            On 03/01/2012 10:06 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:
                             
                            + 1 to Flavius' idea (Spike Story or Spike Task), but I also use Backlog Grooming (grooming next sprint's items during the current sprint) to help highlight these risks.  If you have a good BG practice, and the spike period (to assess tool viability/mitigate risk) is small enough, you don't need a backlog item for it -- it's just a task someone does in their spare moments in the sprints proceeding the one when the new tool is needed.  If the spike period is bigger, than I'd say to put a spike on the product backlog or the sprint backlog.
                             
                            -------
                            Charles Bradley
                            http://www.ScrumCrazy.com




                            From: Flavius Stef <flavius_stef@...>
                            To: scrumdevelopment@yahoogroups.com
                            Sent: Thursday, March 1, 2012 9:15 AM
                            Subject: Re: [scrumdevelopment] Assumptions that bite back



                            Hi pctnmrk,

                            Break the work item in 2: a spike (time-boxed experiment) in the current sprint and the actual work (based on the newly acquired knowledge) in the next sprint.

                            Flavius

                            On 03/01/2012 05:51 PM, pctnmrk wrote:
                             
                            Some questions arose during a recent Retro...
                             
                            How should we handle technical assumptions during planning?
                            (eg. assuming a third party service is easily integrated with our own solution)
                             
                            How should we best deal with technical difficulties which blow up mid sprint?
                            (eg. finding out the third party service isn't easily integrated)
                             
                            I'd be very interested know if other Agile teams have had experience with this, and I'd appreciate any suggestions or feedback.







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