JIRA Sprint report

[Sundara Rao Damaraju]

I am looking for clarification in the "Sprint report".The team has started with 5 user stories,4 defects are found during the sprint execution. The team did not provide any story point estimates for the newly included defects. When the scrum master asks the team why the estimates are "0", the leader told that the bugs identified are part of the 5 user stories we agreed, hence it is the team's responsibility to complete 5 user stories without bugs. That's the reason the newly identified bugs are having their story points as "0". According to the team their effort is included in the 5 user stories planned.  How should the scrum master resolve the conflict? 
A. Bugs identified must be estimated, if the team is able to complete 5 user stories + 4 newly identified bugs then there may be a problem in planning.   They can absorb some more work. In the above case, the team has delivered more than planned, if we estimate bugs we can streamline velocity or take preventive actions to build quality.

B. Bugs identified must be estimated and low priority stories need to be dropped from this sprint. Then only we can say the team's velocity is stable and numbers can give better predictability.

The SM can convince the team with the above points, Can you please share your comments.

[Sundara Rao Damaraju · Accepted solution]

Thank you so much Mykenna Cepek and Danno. Wish you a happy new year-2021

One common way I have worked with teams, and heard other agile leaders recommend, focuses on when the bug was discovered. If discovered during the same sprint as when the story was implemented, then the bug is simply included as part of the work to complete that story in that sprint - no new story, no new estimate. Perhaps the difficulty of the story was underestimated in planning, but that's a topic for the next retrospective.

Just need clarification on the above lines. Agreed with the rest of your response.  When a significant number of bugs found in the same sprint why we have to refrain from creating new bugs (as issues in JIRA) , linking them to the story, and estimating the story point? Because there is no guarantee that all the newly raised bugs will be fixed in the current sprint. By doing so we will be knowing the actual effort spent on completing the "Sprint goal" and variance.  And I agree if the bugs are cosmetic in nature neither bug creation nor estimation provides value. 

[Mykenna Cepek]

If the new bug issues you're creating are trivial concerns (cosmetic, performance, etc) then there is no problem with creating new bug issues, and linking them, and even estimating them.

But if all those new issues are in future sprints, then you haven't affected the current sprint, and thus will not know "the actual effort spent on completing the Sprint Goal and variance".

If instead you are postponing non-trivial bugs, that is something to be very concerned about. A team shouldn't find themselves in a pattern of regularly putting off newly-implemented bugs. That simply accumulates Tech Debt over time. Ultimately it comes down to what kind of quality you want to be delivering.

The idea of "including the bugs as simply more work on the story in this sprint" is based on several agile concepts:

• The original story had a higher priority than other issues in the sprint, and therefore should be completed first.
• A story isn't "Done" until it achieves the team's "Definition of Done", which hopefully includes something about "no non-trivial bugs remaining".
• It's ok for a story to be more work than anticipated -- figure out how to "save the sprint" as a team, and retro on it in order to learn and do better at estimating future stories.

Hope that helps!

[Sundara Rao Damaraju]

Thank you Mykenna Cepek

[Mykenna Cepek · Accepted solution]

Hi Sundara, it's good that your team is looking at these issues and discussing options with their ScrumMaster.

Jira and the Sprint Report isn't very relevant to your decision. The only overlap appears to be tracking Velocity, and clearly that will be impacted by whether your bug stories have zero points or not.

One common way I have worked with teams, and heard other agile leaders recommend, focuses on when the bug was discovered. If discovered during the same sprint as when the story was implemented, then the bug is simply included as part of the work to complete that story in that sprint - no new story, no new estimate. Perhaps the difficulty of the story was underestimated in planning, but that's a topic for the next retrospective.

If instead a bug is found in a later sprint (after the original implementation story was marked Done), then a new story is warranted, and typically does get a point estimate.

Teams typically use points to help plan for relatively "full sprints". Zero-point stories that represent non-zero effort by the team simply mess up that equation. Points are intended to reflect the effort, complexity, and risk of some work. Does any work really have no effort, no complexity, and no risk?

Note that if bugs found later are pointed, parity suggests that bugs found mid-sprint also have some point impact. I've worked with teams that are open to adjusting the points for a story mid-sprint, and I've worked with teams that would never do that. Find what works best for your team. Or just try something, see how it works, and retro on it.

As for prioritizing bugs (as in your option B), I'd suggest that always be up for discussion. Any time a sprint is impacted (e.g. new urgent work is added, a big story takes much less time than needed, etc), that is an opportunity to make a mid-sprint adjustment. If several bugs in a story this sprint threaten the sprint goal, then take a broad look at the whole sprint. Is this buggy story more important than other work the team could complete? Maybe the right answer is to revert the entire story out of the codebase (or feature-flag it off) for this sprint, and work on something else less risky.

This is less about Jira, and more about how you want to use it. I've tried to use my Agile experience to help explore options and the reasons behind different approaches.

I encourage additional reading, such as this article from my favorite Agilist:

• Should Story Points Be Assigned to a Bug Fixing Story?

Best wishes to you and your team!

[Danno]

@Mykenna Cepekthis is an issue I have as a beginning scrum master. I'm working to implement Agile practices in an environment that has traditionally been a waterfall type of company. I'm having to do this with non-software team members as well as software developers. On top of that, we are having to do work outside of our development work. Our current rule is if it is "walk-in" work we just don't include it in the project. It definitely seems to be affecting our velocity but it is hard to tell what the cause is.

This could be due to how new this process is to the team but I am unable to determine if that is the case. My personal opinion would be to have a separate project to capture this work but I think it should be more of a Kanban type of project. I have no idea how you would measure the effect of this on the sprint but at least you would capture the work.

[Mykenna Cepek]

Often teams will differentiate "bug" work from other work in Jira. That can be using the Issue Type (Bug vs Story), or in other ways (components, custom fields, etc). That helps to gather metrics, and data is always helpful when trying to support the need to change things.

I'd recommend against using a different project, especially if the team is using Scrum for Sprint-based work. Keep all of the team's work in one place.

Remember that one of the things that Agile does is that it uncovers the problems in a team / organization / dept / etc. It doesn't necessarily provide an easy and obvious solution, but knowing where the problems are will allow for thoughtful choices to be made (as opposed to not having a clue, and just moving forward anyway).

Consider letting go of trying to get this "perfect". Let the team struggle with one way of working (e.g. zero-point bug stories). Focus instead on helping them learn from how that went. Ask questions in the retro: "is this approach working for us?", "can we trust our velocity?", "do we want to try anything different next sprint?". Let them figure out the next thing to try. You might be surprised -- I frequently am!

Taking an iterative approach to improving over time does a number of things. It allows the team to see the impact of the problem themselves, they make decisions as a group (which helps them take ownership of the process), and they can use you as a source of information about Agile, Scrum and Kanban (rather than someone with all the answers).

[Danno]

Good point. My thinking is that we aren't capturing all of the work that is happening. I get that some of this work isn't part of the main project goals so it's perceived we don't want to include it in the Total work required for the project. One of the reasons given for not including them actually came from the software team manager. He was using it as a way to differentiate from his team's planned work and "emergency fixes" that would impact his team's sprints (he was the only one using Scrum at the time).

I followed your link to Mike's site so I'll go check out what I can find there. I do like your suggestion to keep bringing up these types of issues in the retrospectives which surprisingly have been going better than I expected. Thanks.