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

Re: [scrumdevelopment] Seperate engineering and QA backlog, burndown and velocity

Expand Messages
  • Tobias Mayer
    This reminds me of a quote I stole from the agile-testing list about 18 months ago. and have used in a number of presentations. An Agile project begins when
    Message 1 of 7 , May 3, 2006
      This reminds me of a quote I stole from the agile-testing list about 18 months ago. and have used in a number of presentations. 
      "An Agile project begins when testers convert high-level requirements into testable specifications."
      In other words, testers are at the beginning, not the end of the process.  I cannot loacte the source of the quote now, but there is a little more on this subject from Phlip in this post:

      Ramon Davila <davilameister@...> wrote:
      I have been working on cross-functional teams for the last three years, and we found that the Practice of Test Driven Development have helped the teams get over the artificial need to split among functional lines. TDD has the virtue to include the QA folks earlier in the development process, since they are usually responsible for the creation and maintenance of Functional tests. We have learned that once teams have fully embrace TDD, Testers become heavily involved in the ongoing development effort, instead of just being at the end of the queue, waiting to validate if the work is done.

      Ramon Davila

      On 5/2/06, Mark Striebeck <mark.striebeck@...> wrote:
      We tried for some time to include QA in our iteration planning - added testing tasks to the backlog, estimated them and tracked all tasks (engineering and QA) together in burndown and velocity graphs.

      So far, the teams of all the projects don't see any benefit in this. The overall engineering burndown (instead of individual burndowns for each engineer) makes sense as the engineers can shift tasks around depending on who has finished his/her task. But there is no exchange with QA, an engineer can't do the QA and vice versa.

      In our retrospective we discussed today to track engineering and QA in seperate burndown charts and velocities. I know that this does not support the overall team spirit and could lead to fingerpointing ("we didn't finish our iteration because xy isn't done"). But that's not really a concern with the teams I'm working with. They (engineering and QA) really liked the idea and think that it can help scheduling much better then the overall velocity.

      Does anybody have any experience with this?

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



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