Team Velocity Concerns
- 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
- 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: