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

Team Velocity Concerns

Expand Messages
  • gthackham
    We have been using Scrum for about 5 months now on our patch releases. These have been very successful and only one of them needed an additional Sprint to be
    Message 1 of 2 , Jun 19, 2006
      We have been using Scrum for about 5 months now on our patch releases.
      These have been very successful and only one of them needed an
      additional Sprint to be added in order to finalize the release.

      We were able to achieve the goal of the Patch in a single Sprint. Now we
      are starting our first Service Pack which requires 2 Sprints. Questions
      and concerns have been raised by the team on "lumping" the Engineering
      and QC velocity together.

      This did not cause us any issues in the patch but now that we are
      dealing with a lot more scope and longer time lines there is a concern
      that the Engineering velocity may be giving us a false sense of security
      around whether QC can complete their Sprint tasks.

      How would you answer these challenges? I must confess although I am a
      strong supporter of Scrum I would like to be able to explain why it
      works. Do I need a more sophisticated burn down chart?

      Any help would be greatly appreciated.

      thanks, i have already enjoyed reading some of the interesting thread
      discussions.

      Gary
    • Nicholas Cancelliere
      How are you measuring velocity right now? By saying QC - I assume you mean quality control. Is there a reason that your Quality Control team is tasked in a
      Message 2 of 2 , Jun 24, 2006
        How are you measuring velocity right now?  By saying QC - I assume you mean quality control.  Is there a reason that your Quality Control team is tasked in a separate sprint and not working along with the Engineering team?


        On Jun 19, 2006, at 4:27 PM, gthackham wrote:


        We have been using Scrum for about 5 months now on our patch releases.
        These have been very successful and only one of them needed an
        additional Sprint to be added in order to finalize the release.

        We were able to achieve the goal of the Patch in a single Sprint. Now we
        are starting our first Service Pack which requires 2 Sprints. Questions
        and concerns have been raised by the team on "lumping" the Engineering
        and QC velocity together.

        This did not cause us any issues in the patch but now that we are
        dealing with a lot more scope and longer time lines there is a concern
        that the Engineering velocity may be giving us a false sense of security
        around whether QC can complete their Sprint tasks.

        How would you answer these challenges? I must confess although I am a
        strong supporter of Scrum I would like to be able to explain why it
        works. Do I need a more sophisticated burn down chart?

        Any help would be greatly appreciated.

        thanks, i have already enjoyed reading some of the interesting thread
        discussions.

        Gary


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