AnsweredAssumed Answered

Help with defect managment

Question asked by 0caba82b53287e4c9ebf29a1df429f1b on Jul 15, 2015
Latest reply on Aug 3, 2015 by maksya
Hi,

I am, maybe not new to Rally, but I want to move up a level and really get into the tool.

I am, and I make no apology for this, a QC guy. I have spent years working with it and I know the API well. I am used to being able to arrange things in a way that suits me and makes sense.

I am now working on a data warehousing programme that is being run as two sub-projects. One concentrating on a Cognos based UI and custom admin suite and the other concentrating on the extract / transform / load of the warehouse and data marts.

We are running in two week sprints and the ETL work simply does not fit into these timeboxes

As a lead QA on this work the bulk of my inbound dependencies arrive the day before the end of the sprint. To address this we are creating multiple user stories, one for development to run in sprint n and one for QA that will run in n+1

This is making planning difficult, but nowhere near as difficult as the defect management.

Our defects do not, in general, originate from the testing. Yes we get the work 95% right on the ETL side but as the work moves to the UI / Cognos team the requirements and specifications evolve to be "what we need" rather than "what we thought we needed".

Once we move to UAT, given our data is very specialised and our business rules are very complex (also in some cases a matter of opinion depending on which department you are talking to but we have all been there) we also get a number of issues in that are not associated with any user story.

It's almost as if we had an epic defined as "Everything must be perfect" and of course as a data warehousing / BI programme this is of course true. Everything must be perfect or it will have anomalies and glitches.

So these defects will not be addressable in a single sprint. There may be multiple sprints to identify root causes, produce a fix, get that tested at the database level, promote it through multiple environments, test it again at the UI level etc.

My immediate issue is that I cannot split the tasks on a defect across multiple sprints. Nor can I split tasks on a user story across multiple sprints. I cannot treat tasks in a hierarchical way or assign dependencies to tasks, my mindset seems to be fixed in MS-Project & Quality Centre for large infrastructure programmes, which is what I generally do, not short, reasonably trivial updates to a web-app that can be run through Jenkins and tested with selenium or QTP or any of the alternatives.

So, if anyone has any advice I would be all ears. how do I arrange my user stories. what artifacts can I use within rally to get a better view of things that take three months to deliver ( and please don't say "break it down into smaller bits" because the business set and define the user stories not the developers ) and finally how on earth does one manage defects with this tool?

Thanks.

-Ed.
 

Outcomes