Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Hi,
In my previous post (Sprint Burndown & Release Burndown Charts), i had indicated that we are working towards having QA tasks too into the Sprint (which wasn't the case, until now)..
Just to give a high level view of what the QA tasks, would look like:
1. Bug Verification
2. New Feature validation
3. Regression Testing
I was thinking of doing the following way, but i am not sure if this is the best way:
1. Bug Verification - have a separate ticket called "Bug Verification" and have QA provide the Story Points for verifying all the bugs.
2. New Feature validation - Create a sub-task under this User Story and have QA provide the story point for validating the same.
3. Regression Testing - create a "Regression Test" task and have the QA provide the Story points.
Appreciate any inputs, as we are at a very early stage of implementing this process, so it will be a good time to refine it and indicate to the team. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Thanks for amplifying my answer, Kiron.
I like to decompose stories down to one-day deliverables. That means all analysis, design, development, testing and documentation for that deliverable is to be done in one day.
Not only does it make it easier to track progress but it also makes it easier to plan a sprint's content. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Oct 06, 2017 3:02 AM
Replying to Robert Poddar
...
Hi Sergio,
Yes, we aren't working in a pure Agile environment, but in a quasi or hybrid environment. With this setup, i wanted to know how best to include the QA tasks into the Sprint, since QA is tasks are currently out of the Sprint.
thanks
Robert.
Inside the sprint you are making quality assurance and quality control activities from requirements to delivery. The point is you have to detect the tools and method you use to do that. For example, if you are using XP then you are working side by side with the person that are giving the requirements and are visualizing the results. Then, in this case, quality assurance and quality control are being performed becuase you are making verification and validation. That is one of the advantages of agile based methods and at the same time it is one of the hardest things to manage. Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Oct 06, 2017 2:53 AM
Replying to Robert Poddar
...
Hi Stephane,
Actually, the QA tasks are currently out of the Sprint scope. From a burndown chart perspective, we aren't getting a clear picture on the status of the Sprint, since QA tickets are not in the Sprint; hence i am finding the best way to bring in the QA into the Sprint and also be able to have a better Burndown Chart..
thanks
Robert
Hi Stephane
Ok, will start to include the QA effort as part of the User Story..how should i handle other QA task such as regression testing, volume testing, performance testing? should i have separate tickets for each of those tickets? (or) have a single task which incorporates all these tests?
Robert.
...
1 reply by Stéphane Parent
Oct 13, 2017 7:17 AM
Stéphane Parent
...
You have a few choices, Robert.
You could do the minimal amount of non-functional testing (NFT) required for each story. This would assume that you can readily focus NFT down to a granular amount relevant to your stories.
You could also include full NFT in each sprint, regardless of content. The problem with this approach is you are almost stuck doing it only after all development is done. That doesn't really fit well in the agile framework. It also put NFT as the last piece keeping the sprint from being completed.
Finally, you could keep NFT out of the sprint and perform it as part of your release planning. Given that releases are not part of the sprint process, this means you don't have to force-fit NFT into sprints. The drawback is that you will likely be doing NFT for more than one sprint, thus making it more difficult to trace defects back to the injecting story.
As you can see, each approach has its pros and cons. You will have to decide what makes the most sense for your organization.
Saving Changes...
Robert PoddarProject Manager| Identiv Private LimitedChennai, Tamil Nadu, India
Oct 06, 2017 9:13 AM
Replying to Kiron Bondale
...
Robert -
as Stéphane indicated above, any individual role's tasks (e.g. development, design, documentation, quality) required to complete a story should be included as part of the TEAM sizing done. Story decomposition into tasks should be done only if it is needed to create any understanding of what's needed otherwise it is documentation for documentation sake.
Kiron
Hi Kiron,
Ok, will talk to the team and have the QC/QA include their efforts into the user story, which will also have the development efforts. I just posted a response to Stephan, asking how should i handle the other "regular" task such as regression testing, performance testing, volume testing etc? Should i have separate tasks for these tests (or) have a single task and size it, by incorporating all these tests.
Robert. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Oct 13, 2017 6:48 AM
Replying to Robert Poddar
...
Hi Stephane
Ok, will start to include the QA effort as part of the User Story..how should i handle other QA task such as regression testing, volume testing, performance testing? should i have separate tickets for each of those tickets? (or) have a single task which incorporates all these tests?
Robert.
You have a few choices, Robert.
You could do the minimal amount of non-functional testing (NFT) required for each story. This would assume that you can readily focus NFT down to a granular amount relevant to your stories.
You could also include full NFT in each sprint, regardless of content. The problem with this approach is you are almost stuck doing it only after all development is done. That doesn't really fit well in the agile framework. It also put NFT as the last piece keeping the sprint from being completed.
Finally, you could keep NFT out of the sprint and perform it as part of your release planning. Given that releases are not part of the sprint process, this means you don't have to force-fit NFT into sprints. The drawback is that you will likely be doing NFT for more than one sprint, thus making it more difficult to trace defects back to the injecting story.
As you can see, each approach has its pros and cons. You will have to decide what makes the most sense for your organization. Saving Changes...
