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

Re: [scrumdevelopment] Re: Sprint Backlog item sent for testing

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Samer, Given your answers to the questions below, I would coach you towards a strategy something like: a)  If the bug (defining bug as you did in this
    Message 1 of 27 , Aug 29, 2011
    • 0 Attachment
      Samer,

      Given your answers to the questions below, I would coach you towards a strategy something like:

      a)  If the "bug" (defining bug as you did in this conversation, some undesirable behavior discovered after a SBI is 'dev complete' but before the PBI  is 'complete/accepted') is fairly small and fairly easy to fix, verbal communication is probably best.  Prefer this strategy the most.

      b) If verbal communication is not sufficient, recording the bug in some tool is probably ok to retain details that might be required to fix the bug or re-test it.  I would suggest recording only the minimum amount of information that could possibly work.

      c)  If the presence of the bug significantly impacts the "amount of remaining work" for that SBI, then you might consider creating new tasks to represent this new work known, or just adjusting the estimates on the tasks you already have to represent that work for the SBI.  The amount of time taken to adjust the amount of work remaining should be weighed against the information it provides.  In other words, the re-estimating may or may not be a valuable use of your team's time -- the team should consider that aspect.  Having a dev and tester "share" a task that is bounced back and forth can be very problematic when it comes to transparency.

      As others have said, using these extra "bug fixing" activities as a way to identify developer deficiencies is not an idea that is consistent with Scrum.

      As a Scrum Coach and/or ScrumMaster, I prefer to take a more team oriented approach to the issues you describe, along the lines of asking some questions in a retrospective like:
      - (My strong preference is to listen for someone on the team to mention the issue first, even if only tangentially, and then encourage the team to do a root cause analysis.  If no one mentions it, then I try the below things)
      - What are the most valuable things we could try to get more product backlog items "done" and bug free by the end of the Sprint?
      - It seems like we have a lot of SBI's that seem to bounce back and forth between a developer and a tester.  Is that back and forth time valuable and efficient?  If not, what can we do to make that work better?  What would our world look like if there was no back and forth time?

      I prefer to let the team do the analysis and come up with possible solutions.

      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
      My blog: http://scrumcrazy.wordpress.com/

      From: Samer <samerghosn@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Saturday, August 27, 2011 1:31 AM
      Subject: [scrumdevelopment] Re: Sprint Backlog item sent for testing




      Hi Charles,
      Yes, I am using Microsoft Team Foundation Server 2010 and the scrum for team system template 2.x

      About the verbal communication, I know it's faster than e-mails but sometimes you need screenshots and I am trying to minimize talking when possible to have a kind of a quiet environment in order not to disturb other developers working on other tasks. I know sometimes you have to communicate verbally to explain things but we usually record everything by e-mails or inside Bugs/SBIs History section.

      About logging a new bug if it will take sometime, I agree but closing the original task will give wrong input as if the task is completed, what if the tester started with testing a task (original time : 6 hours) and found a bug that needs 3 hours to fix, he will log it as a bug but he cannot close the original one because the tester has just started and needs to resume testing after the new bug is solved. OTOH if he changes the task state to "In progress" and creates a bug, he will have 2 tasks to maintain and to change the state each time he wants to send it to the tester.

      About your questions:
      1.  Is your team co-located?
      Answer:same floor but different rooms
      2.  Is your team using an electronic tool to track the SBI's?
      Answer: We use Microsoft Team Foundation Server
      3.  Does your team estimate SBI's?
      Answer: Yes
      4.  Are your tasks generally designed for one person, or does the same task 'travel' between dev and test?
      Answer: Most of the time, tasks are designed for 1 developer but it goes back and forth between him and the tester.
      5.  Will bugs get "lost in the cracks" if your team does not record them in some way?
      Answer: sometimes, and to avoid misunderstanding during verbal communication.

      Thanks for the Article, I will check it :)

      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
      >
      > Samer,
      >
      > I'm assuming you're using some sort of electronic tool to manage Sprint Backlog Items (sometimes called tasks), which is one way to manage a Sprint Backlog.  Please correct me if I'm wrong. 
      >
      >
      > Based on my coaching experiences...
      >
      > For these kinds of intra-Sprint bugs, and assuming that one fixes all bugs before a PBI is considered complete, my preferred strategy is to have the tester simply have a verbal conversation with the developer, if that is effective.  Verbal conversations are most effective when the bug is small and fairly easily fixable.  I would also prefer that do some some pairing, if valuable, on fixing the problem.  It might also be worth a conversation with the PO to determine if the behavior is really a bug. 
      >
      >
      > OTOH, sometimes people get to working on so many things that they forget what happens in a verbal conversation, so the bug might need to be recorded separately somewhere so it is not forgotten.  I would say that one should choose verbal over recorded if possible, but the exact strategy will depend on the team and situation context.  Another possible consideration is how co-located or dispersed the team is.
      >
      >
      > I don't like electronic tools, so when teams ask me something similar to what you're asking, I usually give them the answer based on a manual Scrum board (Sprint Backlog information radiator), and let them map the solution to how their tool does stuff.
      >
      > In short, if the bugs are small enough, I just suggest that the dev put the same SBI task back to "in progress", and then move it forward again when they're done fixing.  If it seems like this is going to make the amount of work remaining in the Sprint (what we used to call the burndown) highly inaccurate, then I suggest that the dev ignore the old task and create a new task(maybe a pink sticky to indicate bug?) and estimate it so that the amount of work remaining is more accurate.  I usually don't care about a task that moves back and forth between dev and test unless it totally obscures the amount of work remaining. 
      >
      >
      > I don't find a lot of value in tracking the number of bugs per SBI.  It's usually pretty obvious when a lot of bugs are found, and it can be discussed in a retrospective.
      >
      > So, if I wanted to get at the root of your question, I would ask:
      > 1.  Is your team co-located?
      > 2.  Is your team using an electronic tool to track the SBI's?
      > 3.  Does your team estimate SBI's?
      > 4.  Are your tasks generally designed for one person, or does the same task 'travel' between dev and test?
      > 5.  Will bugs get "lost in the cracks" if your team does not record them in some way? 
      >
      >  
      > This article may also help, but note that is based on the 2010 Scrum Guide:
      > http://www.scrumcrazy.com/Sprint+Tasking+Tips
      >
      >
      > -------
      > Charles Bradley, CSM, PSM I
      > Experienced Scrum Coach
      > Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
      > My blog: http://scrumcrazy.wordpress.com/
      >
      >
      > >________________________________
      > >From: Samer <samerghosn@...>
      > >To: scrumdevelopment@yahoogroups.com
      > >Sent: Thursday, August 25, 2011 2:41 PM
      > >Subject: [scrumdevelopment] Sprint Backlog item sent for testing
      > >
      > >Hi,
      > >A Product Backlog Item contains 1 Sprint Backlog Item for example.
      > >The developer works on the SBI and sends it for testing, if the tester finds a bug should he return the SBI to the developer with his comments in history or should he create a bug under the same PBI?
      > >
      > >Approach 1 : If the tester founds 10 bugs in the same SBI then this SBI will be kept send back and forth between the developer and the tester and there is no way to know how many bugs were found in the SBI itself.
      > >
      > >Approach 2 : If the tester creates a separate entry for each bug, then we can easily identify the number of bugs generated by the developer and measure the time spent on fixing bugs, however what happens to the SBI during this cycle of bugs? , it cannot stay with the developer and it cannot stay with the tester, should it also change state along with the bug? but this would be double entry for both developer and tester.
      > >
      > >What do you think?
      > >
      > >
      > >
      > >------------------------------------
      > >
      > >To Post a message, send it to:  scrumdevelopment@...
      > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      >




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

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

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

      <*> Your email settings:
          Individual Email | Traditional

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

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

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

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



    • Dan Rawsthorne
      Beautiful, Dave... Dan ;-) ... Beautiful, Dave... Dan  ;-) On Mon, Aug 29, 2011 at 7:54 AM, David A Barrett wrote:   ... than 1
      Message 2 of 27 , Aug 29, 2011
      • 0 Attachment
        Beautiful, Dave... Dan  ;-)

        On Mon, Aug 29, 2011 at 7:54 AM, David A Barrett <dave.barrett@...> wrote:
         

        >Hi,
        >Each developer for 1 task but more than 1 developer in the team.
        >Once you have the number of bugs produced during a sprint you
        >can tell what caused the delay and which developer you need
        >to work on more to improve.

        Samer,

        There's definitely something missing here.  

        The concept of a "bug" during development doesn't make any sense at all.  All that it means is that the development isn't completed yet.  The Team is responsible for getting the Sprint Item done, and "done" usually (ie: always!) means that it's tested and bug free.  Even in the case where you hand out tasks to individual Team members (not recommended, btw) they still need to adhere to the definition of done, which means they need to get it clean.

        What I suspect that you have happening is that the programmers are tossing stuff over the wall to the QA stage and declaring, "Done!".  Then the work comes back as a bug fix.  What you need to do is get to the point where the programmers are calling something done *after* it's been tested.  

        What you really, really, really need to do is to knock down the wall and bring the testers in with the developers.  Make QA part of the programming process.  

        The other thing I'd do, is stop handing out any "credit" for work that hits the end of the Sprint with *any* bugs.  Count it as incomplete, and don't let it be presented at the end of Sprint meeting as an accomplishment.  Make sure that it's transparent, and don't allow the undelivered work to slide by unnoticed.  

        As to how many bugs are being produced by each programmer?  That's important to you only because you've made the quantity of stuff tossed over the wall to QA the metric you're measuring.  Throw out that metric.  If you need a metric, then count the number of tasks that are truly "done".  Because, in real life, that's all that matters.  The PO doesn't care how much stuff went to QA, he cares about how much stuff came out of QA clean.

        Finally, consider this:  The phrase "...and which developer you need to work on more..." is very disturbing in a Scrum context.  One of the things it says is that the Team is being run in a command and control way, with tasks handed out and management monitoring indivdual performance and all the rest.  More than anything else, it takes away the absolute best answer that anyone could give you to the problem you've described.  That answer is,  "Why don't you ask the Team to figure out how to fix the problem?"  



        Dave Barrett


        This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

        Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.


      • Samer
        Thank you Charles and for the rest of the guys. This discussion was extremely helpful :)
        Message 3 of 27 , Aug 30, 2011
        • 0 Attachment
          Thank you Charles and for the rest of the guys.
          This discussion was extremely helpful :)

          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
          >
          > Samer,
          >
          > Given your answers to the questions below, I would coach you towards a strategy something like:
          >
          >
          > a)  If the "bug" (defining bug as you did in this conversation, some undesirable behavior discovered after a SBI is 'dev complete' but before the PBI  is 'complete/accepted') is fairly small and fairly easy to fix, verbal communication is probably best.  Prefer this strategy the most.
          >
          > b) If verbal communication is not sufficient, recording the bug in some tool is probably ok to retain details that might be required to fix the bug or re-test it.  I would suggest recording only the minimum amount of information that could possibly work.
          >
          > c)  If the presence of the bug significantly impacts the "amount of remaining work" for that SBI, then you might consider creating new tasks to represent this new work known, or just adjusting the estimates on the tasks you already have to represent that work for the SBI.  The amount of time taken to adjust the amount of work remaining should be weighed against the information it provides.  In other words, the re-estimating may or may not be a valuable use of your team's time -- the team should consider that aspect.  Having a dev and tester "share" a task that is bounced back and forth can be very problematic when it comes to transparency.
          >
          >
          > As others have said, using these extra "bug fixing" activities as a way to identify developer deficiencies is not an idea that is consistent with Scrum.
          >
          >
          > As a Scrum Coach and/or ScrumMaster, I prefer to take a more team oriented approach to the issues you describe, along the lines of asking some questions in a retrospective like:
          > - (My strong preference is to listen for someone on the team to mention the issue first, even if only tangentially, and then encourage the team to do a root cause analysis.  If no one mentions it, then I try the below things)
          >
          > - What are the most valuable things we could try to get more product backlog items "done" and bug free by the end of the Sprint?
          > - It seems like we have a lot of SBI's that seem to bounce back and forth between a developer and a tester.  Is that back and forth time valuable and efficient?  If not, what can we do to make that work better?  What would our world look like if there was no back and forth time?
          >
          > I prefer to let the team do the analysis and come up with possible solutions.
          >
          >
          > -------
          > Charles Bradley, CSM, PSM I
          > Experienced Scrum Coach
          > Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
          > My blog: http://scrumcrazy.wordpress.com/
          >
          >
          > >________________________________
          > >From: Samer <samerghosn@...>
          > >To: scrumdevelopment@yahoogroups.com
          > >Sent: Saturday, August 27, 2011 1:31 AM
          > >Subject: [scrumdevelopment] Re: Sprint Backlog item sent for testing
          > >
          > >
          > >
          > >
          > >Hi Charles,
          > >Yes, I am using Microsoft Team Foundation Server 2010 and the scrum for team system template 2.x
          > >
          > >About the verbal communication, I know it's faster than e-mails but sometimes you need screenshots and I am trying to minimize talking when possible to have a kind of a quiet environment in order not to disturb other developers working on other tasks. I know sometimes you have to communicate verbally to explain things but we usually record everything by e-mails or inside Bugs/SBIs History section.
          > >
          > >About logging a new bug if it will take sometime, I agree but closing the original task will give wrong input as if the task is completed, what if the tester started with testing a task (original time : 6 hours) and found a bug that needs 3 hours to fix, he will log it as a bug but he cannot close the original one because the tester has just started and needs to resume testing after the new bug is solved. OTOH if he changes the task state to "In progress" and creates a bug, he will have 2 tasks to maintain and to change the state each time he wants to send it to the tester.
          > >
          > >About your questions:
          > >1.  Is your team co-located?
          > >Answer:same floor but different rooms
          > >2.  Is your team using an electronic tool to track the SBI's?
          > >Answer: We use Microsoft Team Foundation Server
          > >3.  Does your team estimate SBI's?
          > >Answer: Yes
          > >4.  Are your tasks generally designed for one person, or does the same task 'travel' between dev and test?
          > >Answer: Most of the time, tasks are designed for 1 developer but it goes back and forth between him and the tester.
          > >5.  Will bugs get "lost in the cracks" if your team does not record them in some way?
          > >Answer: sometimes, and to avoid misunderstanding during verbal communication.
          > >
          > >Thanks for the Article, I will check it :)
          > >
          > >--- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@> wrote:
          > >>
          > >> Samer,
          > >>
          > >> I'm assuming you're using some sort of electronic tool to manage Sprint Backlog Items (sometimes called tasks), which is one way to manage a Sprint Backlog.  Please correct me if I'm wrong. 
          > >>
          > >>
          > >> Based on my coaching experiences...
          > >>
          > >> For these kinds of intra-Sprint bugs, and assuming that one fixes all bugs before a PBI is considered complete, my preferred strategy is to have the tester simply have a verbal conversation with the developer, if that is effective.  Verbal conversations are most effective when the bug is small and fairly easily fixable.  I would also prefer that do some some pairing, if valuable, on fixing the problem.  It might also be worth a conversation with the PO to determine if the behavior is really a bug. 
          > >>
          > >>
          > >> OTOH, sometimes people get to working on so many things that they forget what happens in a verbal conversation, so the bug might need to be recorded separately somewhere so it is not forgotten.  I would say that one should choose verbal over recorded if possible, but the exact strategy will depend on the team and situation context.  Another possible consideration is how co-located or dispersed the team is.
          > >>
          > >>
          > >> I don't like electronic tools, so when teams ask me something similar to what you're asking, I usually give them the answer based on a manual Scrum board (Sprint Backlog information radiator), and let them map the solution to how their tool does stuff.
          > >>
          > >> In short, if the bugs are small enough, I just suggest that the dev put the same SBI task back to "in progress", and then move it forward again when they're done fixing.  If it seems like this is going to make the amount of work remaining in the Sprint (what we used to call the burndown) highly inaccurate, then I suggest that the dev ignore the old task and create a new task(maybe a pink sticky to indicate bug?) and estimate it so that the amount of work remaining is more accurate.  I usually don't care about a task that moves back and forth between dev and test unless it totally obscures the amount of work remaining. 
          > >>
          > >>
          > >> I don't find a lot of value in tracking the number of bugs per SBI.  It's usually pretty obvious when a lot of bugs are found, and it can be discussed in a retrospective.
          > >>
          > >> So, if I wanted to get at the root of your question, I would ask:
          > >> 1.  Is your team co-located?
          > >> 2.  Is your team using an electronic tool to track the SBI's?
          > >> 3.  Does your team estimate SBI's?
          > >> 4.  Are your tasks generally designed for one person, or does the same task 'travel' between dev and test?
          > >> 5.  Will bugs get "lost in the cracks" if your team does not record them in some way? 
          > >>
          > >>  
          > >> This article may also help, but note that is based on the 2010 Scrum Guide:
          > >> http://www.scrumcrazy.com/Sprint+Tasking+Tips
          > >>
          > >>
          > >> -------
          > >> Charles Bradley, CSM, PSM I
          > >> Experienced Scrum Coach
          > >> Currently Seeking engagement as Scrum Coach or Scrum Master in Denver area
          > >> My blog: http://scrumcrazy.wordpress.com/
          > >>
          > >>
          > >> >________________________________
          > >> >From: Samer <samerghosn@>
          > >> >To: scrumdevelopment@yahoogroups.com
          > >> >Sent: Thursday, August 25, 2011 2:41 PM
          > >> >Subject: [scrumdevelopment] Sprint Backlog item sent for testing
          > >> >
          > >> >Hi,
          > >> >A Product Backlog Item contains 1 Sprint Backlog Item for example.
          > >> >The developer works on the SBI and sends it for testing, if the tester finds a bug should he return the SBI to the developer with his comments in history or should he create a bug under the same PBI?
          > >> >
          > >> >Approach 1 : If the tester founds 10 bugs in the same SBI then this SBI will be kept send back and forth between the developer and the tester and there is no way to know how many bugs were found in the SBI itself.
          > >> >
          > >> >Approach 2 : If the tester creates a separate entry for each bug, then we can easily identify the number of bugs generated by the developer and measure the time spent on fixing bugs, however what happens to the SBI during this cycle of bugs? , it cannot stay with the developer and it cannot stay with the tester, should it also change state along with the bug? but this would be double entry for both developer and tester.
          > >> >
          > >> >What do you think?
          > >> >
          > >> >
          > >> >
          > >> >------------------------------------
          > >> >
          > >> >To Post a message, send it to:  scrumdevelopment@
          > >> >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@! Groups Links
          > >> >
          > >> >
          > >> >
          > >> >
          > >> >
          > >> >
          > >>
          > >
          > >
          > >
          > >
          > >------------------------------------
          > >
          > >To Post a message, send it to:  scrumdevelopment@...
          > >To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.