13509Re: Seperate engineering and QA backlog, burndown and velocity
- May 2 9:47 PMMark,
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
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,
--- In email@example.com, "Mark Striebeck"
> 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
> who has finished his/her task. But there is no exchange with QA, anengineer
> can't do the QA and vice versa.support
> 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'tfinish
> our iteration because xy isn't done"). But that's not really aconcern with
> the teams I'm working with. They (engineering and QA) really likedthe idea
> and think that it can help scheduling much better then the overallvelocity.
> Does anybody have any experience with this?
- << Previous post in topic Next post in topic >>