How to monitor issues that enter the sprint after it has started

Elena Labiaga Ferrer

Hello,

I'm looking for suggestion about how to handle this problem.

We are a soft. dev team using scrum, with sprint of 2 weeks duration.

Every sprint we commit for some story points, and end up closing the sprint with a higher scope than committed. 
Im trying to add visibility to those issues which enter the sprint when its already started. They are coming from different sources, but basically it is QA finding bugs and reporting them about products that are compromised in the sprint time. So it is fine that they do that, still we want a better visibility about those.

It's very time consuming to see those issues one by one, or entering date rate. I would like something more visual.
We are using the flag option already for a different matter, and I'm disappointed to see there are no other flags type (are they and I just don't see them?)

We consider adding a new epic for these kind of issues, but accounting cannot go with that option, since issues should belong to their project.

How do you organize these issues in other teams?

Thanks!!

Scott Theus

Hi @Elena Labiaga Ferrer ,

Apologies in advance for the long "essay" I think this can be resolved with a small process change;  Ii sounds like there are two or three behaviors at issue here. 

First, you mentioned that "QA (is) finding bugs and reporting them about products that are compromised in the sprint time." I assume those defects are the result of development work during the sprint. If this is the case then they should be reported as bugs for tracking purposes, added to the sprint, but not estimated with story points. These defects should be considered part of the original scope of the story, not as additional work.  If a story has bugs associated with it when the sprint ends then the story is not "shippable" and therefor not moved to "DONE" at the end of the sprint. That will keep your sprint burndown chart from becoming a "burn-up" chart and will reflect the team's true velocity.  (Note that over time this will have the added effect of improving the team's quality; it makes the developer accountable for fixing their defects as part of the original work, not as "extra" story points they completed on top of what was assigned during the sprint. Further, by not accepting a story with bugs as "DONE" the Scrum Team is held accountable for not completing the sprint.)

If, however, the issues are found outside of the sprint during a separate QA process (e.g. QA testing of deliverable from the last sprint) then they should be reported as bugs and estimated with points and prioritized by the Product Owner as part of the Product Backlog. 

Second, once those two sources of defects are addressed the Scrum Team should not be working on anything that is not in the sprint. If a defect is reported by QA outside of the current sprint in the second scenario above then the Scrum Team does not work on it. Neither the Scrum Master nor the Scrum Team should be adding issues to the sprint once it has started without the express instruction from the Product Owner AND without either removing an equal number of story points. If the team has bandwidth to complete additional issues during the sprint then the PO should tell the SC what items from the product backlog  should be worked on next. Those added issues should be estimated and over time will help the team understand their true velocity.

Finally, any issue added to the sprint after the sprint has started or completed outside of the will be reflected in the Sprint Burndown report. The report flags issues added to the sprint automatically by marking them with an asterisk (*). It also includes a section for issues completed outside of the sprint, and will reflect changes in story points on issues during the sprint. 

I hope this helps!

-Scott