2

I am trying to decide how to deal with bugs found in sprint in the context of a team and a program backlog.

I have come up with the below process for deciding what to do with a bug and would really appreciate someone confirming or challenging my understanding of the process, specifically when a bug is raised in the program backlog as opposed to the team backlog.

Flow for bugs found in Sprint

Improve this question
1
  • If you’re trying to do Scrum, there’s an answer if you’re following the framework. Otherwise, the real question is why you aren’t doing TDD or whether these bugs put your iteration goal at risk.
    – Todd A. Jacobs ♦
    Jul 13, 2022 at 23:35

1 Answer 1

Reset to default
3

I'm not entirely clear on the relationship between "Sprint", "release", "team backlog" and "program backlog" in your case, so I'll need to keep my answer more general, but it should still be helpful.

If the developer finds the "bug" to be expected behavior but the Product Manager wants different behavior, that doesn't necessarily mean that the expected behavior is expected or desired by the end user. What the developer considers to be "expected behavior" could very well be unacceptable behavior to an end user. In this case, the work to correct the issue may need to happen in the current iteration or release.

This shows a bigger problem. Why is there a delay between finding the bug and talking to the Developers and the Product Manager? Getting everyone together earlier can reduce steps in deciding if the issue found is a bug or a misunderstanding of expected behavior, and if it is a bug, figuring out the impact and priority for fixing it. If it needs to be fixed in the current iteration or release, that may require removing other work, so getting the right people together to have that discussion earlier can reduce the steps in your workflow.

I find the most effective question to ask is what the risk of shipping with the current behavior is. Ideally, all found defects would be fixed before they are released. However, we don't live in an ideal world and need to balance getting feedback on a change or set of changes with introducing potential defects. Only the people closest to the work and the stakeholders can carry out this risk assessment, and the people on the team - the developers, the testers, the product managers - are the right people to do it. The risk assessment can tell you where it goes in priority of all of the other work - the top of the current iteration, closer to the back of the current iteration, or a future iteration.

Improve this answer
2
  • Thank you Thomas. In this scenario, the program backlog describes the roadmap features ( so multiple releases ) whereas the team backlog contains work in progress towards the next release which may be formed of various sprints. This process is specific to what is happening during a sprint. I agree with you about fixing things as soon as they're found and ideally within the same sprint. Question is, if that isn't possible, does the bug go on the Program backlog if it is not a must for the release, so it doesn't clutter the Team backlog.
    – Jack Leon
    Jul 13, 2022 at 13:41
  • 1
    @JackLeon Without knowing more about your framework, I'm not sure where it should go. If you can associate the bug with a particular team (whether it's a feature team, a steam-aligned team, a platform team, or some other kind of team), then I don't see why it wouldn't live on the team backlog until resolved, regardless of what iteration or release it is in. But in your organizational context, it could make more sense to put it on the program backlog and give it to a team later.
    – Thomas Owens ♦
    Jul 13, 2022 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.