The concept of "marking" items across projects with an attribute that
is easily reportable is something I'm proposing in another thread:
http://groups.google.com/group/versionone-users/browse_thread/thread/...
If you think it might help, feel free to weigh in.
As for your suggestion, it is a good stop-gap to helping the problem
(until you can find a way to align QA resource cycles with the dev
teams).
1- For your first question, I'm not understanding what reports these
items would disappear from. Without more background, I'm assuming it
has to do with your implementation and structure in V1.
2- QA folks SHOULD be looking for work in different projects. The dev
team works within a project and the QA resource is behaving as a team
member during that short window of time. The fact that they don't
"want to" is an adjustment they should probably make. Whatever
structure the dev team they are supporting is using, they should be
using. As a matrixed resource, they have an overhead to support and
live in the team's structure even if that is different from team to
team. Not knowing your project structure/implementation... that would
be my gut response to QA. (I used to be a matrixed UX resource, so I
understand the pain they feel).
3- This is where Skips points become a real issue. I can bend my
agile rules to support matrixed resources so that QA folks float. But
allowing them to leave a backlog item open because they aren't ready
creates an impediment for the team. They either need to add a task
stating "update test plan" and whatever else (taking responsibility of
that item's next steps), or they need to be ahead of the dev team with
test plans just like the product owner/analysts/user experience folks.
Good luck!
On Mar 4, 5:51 pm, "Skip Angel" <SAn...@SolutionsIQ.com> wrote:
> Hi Pat,
> I need to ask why QA is a separate team if you know that would be
> ideal.
> In Scrum, there is an expectation that the delivery team has all of
> the people responsible for getting functionality for a product to
> "potentially shippable product increment" state every sprint.
> In order to accomplish this goal, the team needs to do the testing
> activities necessary to meet their standard of quality to have
> something that is shippable.
> Can QA support the product teams in this arrangement? Given my
> experience with other teams, I have not seen it work well. In fact, I
> have found that QA is always a sprint behind (at least) from the team.
> So, it strikes me as curious that the dev team is catching up. How
> is that possible if there is new work to be tested?
> Also, even if things are working pretty well is that sustainable for
> the people in the QA team? How often do they task switch between
> projects? How many hours do they work in each week? It sounds
> pretty complex and chaotic the way you are describing their agility
> ;-)
> I think many of your issues would go away if you integrated QA into
> each of the product teams.
> In addition, I am wondering if throwing it over to the wall for QA has
> been working well for you? I have found that handoffs between teams
> (and the processes/tools to support this) take more time than if the
> teams were collocated working through the tests together. As well,
> the fix and build cycles would be much less because the team is on the
> same page on what needs to be fixed and work correctly.
> Skip Angel
> Agile Coach
> SolutionsIQwww.solutionsiq.com
> -----Original Message-----
> From: versionone-users@googlegroups.com
> [mailto:versionone-users@googlegroups.com] On Behalf Of Pat O
> Sent: Wednesday, March 04, 2009 2:17 PM
> To: VersionOne-users
> Subject: QA/Dev dilema or How do we hand work off from dev to QA?
> I am aware that in an ideal agile world our QA resources would be part
> of our product development teams and this would not be an issue.
> Unfortunately our QA people are more agile than that :-).
> Here is the situation;
> * We have three product teams that are fixing bugs and working on new
> functionality. These teams are fairly static, though there is a
> little churn based on company priorities.
> * We have a QA team whos members move from product team to product
> team on an as needed basis. We tend to push full regression tests on
> one product, then move people to the next product to do regression
> testing there while the dev team "catches up". This means that the QA
> folks are moving pretty constantly.
> * Our dev teams run in sprints of about 4 weeks. (Different product
> groups have different sprint lengths)
> * Our QA team runs in 1 week sprints (no gaps)
> What we would like to do is have the Backlog items marked as ready for
> test (probably a status), have a QA person test the functionality and
> mark the item as closed, or move the status back to in progress if it
> needs more work.
> Issue that have been raised about this;
> * The work will not showup in various reports while waiting for
> testing from the QA team (remember it may take a week or two for QA to
> get around to some of this testing)
> * QA folks don't want to have to go looking for work in the different
> projects
> * QA folks want to be able to leave a backlog open if there is an
> issue with the test plan
> Any suggestions?
> Pat O
