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

13509Re: Seperate engineering and QA backlog, burndown and velocity

Expand Messages
  • Victor Szalvay
    May 2 9:47 PM
    • 0 Attachment
      Newly formed teams go through less productive stages before they start
      performing. The effects you're not seeing may be secondary or
      tertiary effects that will become evident after several sprints and
      most visible after a release.

      One of the main advantages of a cross-functional team is that the team
      is singularly responsible for the delivery of a whole product
      increment (team in this sense includes the PO and SM). There is no
      way any role within the Scrum team (coders, QA, designers, etc.) can
      throw work over-the-fence until ultimately no one is responsible for
      the actual delivery of the software. Rather the team's work is
      evaluated atomically.

      Your coders and QA folks are probably just going through the normal
      stages of team formation and aren't particularly used to the idea of
      working together. The fact that this surfaced is a good thing and
      shows that Scrum is working by surfacing pain points. If you split
      the team along roles then you have effectively abandoned Scrum.

      The others responding to your question have discussed how the two
      groups can better integrate to become a team by decreasing the latency
      between code and test.

      Best of luck,
      -- Victor

      --- In scrumdevelopment@yahoogroups.com, "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
      > 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
      > the overall team spirit and could lead to fingerpointing ("we didn't
      > 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
      > Does anybody have any experience with this?
    • Show all 7 messages in this topic