Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
Sprint Burndown & Release Burndown Charts
Network:47



Hi,
We follow a quasi-Agile development process, wherein the Dev and QA are separate teams. Also, when the Dev team completes all the tickets in the Sprint, the build is then released to QA. As per our current practice, the Dev team only enter their efforts as Story Points, but we are now moving to include the QA tasks too into the Sprint.

How will the Sprint Burndown or Release Burndown Charts look like, when we know that there will be a gap between when Dev mark their task as Done and when QA mark their task as Done, biut both of these are done at different times.

thanks
Robert.
Sort By:
Network:299



Robert -

One approach would be to have the release burndown charts reflecting true "Done-Done" with sizing based on the overall effort & complexity of a given story or work item, but then have the Dev and QA teams size their effort separately such that sprint burndown charts would still be useful for showing their individual team's progress.

This pattern is not optimal - too many opportunities for finger-pointing and delays which could be avoided with true end-to-end delivery happening within the same team.

Kiron
...
1 reply by Robert Poddar
Oct 06, 2017 3:10 AM
Robert Poddar
...
Hi Kiron,

Thanks for the inputs. Let me try out by having separate Sprints for Dev & QA and also need to check how to relate these Sprints into the Release Burndown Chart..

thanks
Robert.
Network:72760



I agree with Kiron.

You may want to consider QC as having their own sprint. That way, you can measure each function's sprints independently. You can even have the development and QC sprints overlap.

It's still not ideal because development is not done until QC says it's done. You are literally stretching your stories over longer periods.

Don't forget that you lose any chance for defects found by QC to be put back in the same build. You don't have a choice but to prioritize the defects, along with your product backlog, for the next iteration.
...
1 reply by Robert Poddar
Oct 06, 2017 3:08 AM
Robert Poddar
...
Hi Stephane,

You are right, by saying that we are stretching the story and until QA/QC says done, the user story is not done. That's exactly how we operate today, whenever QA/QC reports an issue, we triage it and if the PO wants the ticket to be fixed, it is pushed into the next Sprint, else it is left in the Backlog.
From a burndown chart perspective, the user story will stretch until the QA/QC says it is done; even though the implementation has completed much before QA says it is done. Is this understanding correct?

thanks
Robert.
Network:47



Oct 04, 2017 8:40 AM
Replying to Stéphane Parent
...
I agree with Kiron.

You may want to consider QC as having their own sprint. That way, you can measure each function's sprints independently. You can even have the development and QC sprints overlap.

It's still not ideal because development is not done until QC says it's done. You are literally stretching your stories over longer periods.

Don't forget that you lose any chance for defects found by QC to be put back in the same build. You don't have a choice but to prioritize the defects, along with your product backlog, for the next iteration.
Hi Stephane,

You are right, by saying that we are stretching the story and until QA/QC says done, the user story is not done. That's exactly how we operate today, whenever QA/QC reports an issue, we triage it and if the PO wants the ticket to be fixed, it is pushed into the next Sprint, else it is left in the Backlog.
From a burndown chart perspective, the user story will stretch until the QA/QC says it is done; even though the implementation has completed much before QA says it is done. Is this understanding correct?

thanks
Robert.
...
2 replies by Robert Poddar and Stéphane Parent
Oct 06, 2017 7:36 AM
Stéphane Parent
...
It depends on what you mean by implementation, Robert. I would like to think that QC is completed before you actually release software to the client.
Oct 13, 2017 6:53 AM
Robert Poddar
...
Hi Stephane

By "implementation", i mean that developer has completed his coding of the feature/bug.. Yes, as a process once QA completes their validation and if there aren't any critical/major issues, then we go ahead with a release process, wherein the developer lead/QA Lead/Engineering Manager/Project Manager approve the deliverables for release to the market..

thanks
Robert.
Network:47



Oct 04, 2017 8:07 AM
Replying to Kiron Bondale
...
Robert -

One approach would be to have the release burndown charts reflecting true "Done-Done" with sizing based on the overall effort & complexity of a given story or work item, but then have the Dev and QA teams size their effort separately such that sprint burndown charts would still be useful for showing their individual team's progress.

This pattern is not optimal - too many opportunities for finger-pointing and delays which could be avoided with true end-to-end delivery happening within the same team.

Kiron
Hi Kiron,

Thanks for the inputs. Let me try out by having separate Sprints for Dev & QA and also need to check how to relate these Sprints into the Release Burndown Chart..

thanks
Robert.
Network:72760



Oct 06, 2017 3:08 AM
Replying to Robert Poddar
...
Hi Stephane,

You are right, by saying that we are stretching the story and until QA/QC says done, the user story is not done. That's exactly how we operate today, whenever QA/QC reports an issue, we triage it and if the PO wants the ticket to be fixed, it is pushed into the next Sprint, else it is left in the Backlog.
From a burndown chart perspective, the user story will stretch until the QA/QC says it is done; even though the implementation has completed much before QA says it is done. Is this understanding correct?

thanks
Robert.
It depends on what you mean by implementation, Robert. I would like to think that QC is completed before you actually release software to the client.
Network:47



Oct 06, 2017 3:08 AM
Replying to Robert Poddar
...
Hi Stephane,

You are right, by saying that we are stretching the story and until QA/QC says done, the user story is not done. That's exactly how we operate today, whenever QA/QC reports an issue, we triage it and if the PO wants the ticket to be fixed, it is pushed into the next Sprint, else it is left in the Backlog.
From a burndown chart perspective, the user story will stretch until the QA/QC says it is done; even though the implementation has completed much before QA says it is done. Is this understanding correct?

thanks
Robert.
Hi Stephane

By "implementation", i mean that developer has completed his coding of the feature/bug.. Yes, as a process once QA completes their validation and if there aren't any critical/major issues, then we go ahead with a release process, wherein the developer lead/QA Lead/Engineering Manager/Project Manager approve the deliverables for release to the market..

thanks
Robert.
...
1 reply by Stéphane Parent
Oct 13, 2017 7:04 AM
Stéphane Parent
...
Normally, the product owner, usually not one of the roles you listed, approves a build for market release.
Network:72760



Oct 13, 2017 6:53 AM
Replying to Robert Poddar
...
Hi Stephane

By "implementation", i mean that developer has completed his coding of the feature/bug.. Yes, as a process once QA completes their validation and if there aren't any critical/major issues, then we go ahead with a release process, wherein the developer lead/QA Lead/Engineering Manager/Project Manager approve the deliverables for release to the market..

thanks
Robert.
Normally, the product owner, usually not one of the roles you listed, approves a build for market release.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"How far that little candle throws his beams! So shines a good deed in a weary world."

- William Shakespeare

ADVERTISEMENT

Sponsors