Sprint scope change due to bugs and other problems

How are the team identifying the test cases which ought to be applied to Product Backlog items? Why does the Product Owner, who owns the Product Backlog, subsequently observe criteria that are somehow different?

We're doing 1 week sprints until we get used to it and learn better from the process.

I'd challenge the assumption that shorter Sprints are better for learning the process. Yes, the feedback cycles are very short and you are running experiments with both the product and the process, but the rapid changes may be causing more thrashing. Sometimes, a bit of stability is also good for learning. I'd question if both product stakeholders and the team are benefiting from such rapid cycles.

And everyday after the Daily Scrum the dev team sits together with the PO and go through the sprint board Review column, checking the solved issues from last day. Most get solved and move to done. Many other issues are found during those build reviews.

I'd ask why issues are being found. Are the expectations for what it means for the work to be complete made clear and agreed upon by both the Development Team and the Product Owner? If there are clear expectations for what is required, such as the expected behavior and an appropriate level of testing before the review, there shouldn't be "many other issues" found, unless those "other issues" are really ideas for improvement and enhancement and not defects.

I'm also curious why the entire Development Team and the Product Owner are sitting together. It doesn't necessarily seem like the best use of the time of the Development Team. I'm in favor of close collaboration between the Product Owner and the Development Team, but this seems rather intense. Having a better definition of what it means for work to be done and agreeing to it would ensure that the Development Team gets the vast majority of the work that is complete to an acceptable state and the Sprint Review would provide an opportunity to inspect the entire product increment.

Then we add those new issues to the backlog. The problem here is that since we're on a deadline the issues n the backlog have to be moved into the sprint (no matter how many times Ive tolde them is not good to change scope all the time).

This seems reasonable to me. It seems like you aren't adding new scope to the Sprint, but correcting errors with work that the Development Team thought was done, but was not acceptable to the Product Owner. I probably wouldn't be treating these as "new issues" that can be added to the backlog, but simply undone work.

What suggestions do you have for us to tackle this problem? The dev team tests the build for review before handling it to the PO but the issues he finds are always ones we never noticed during our tests. Another recurring problem is that bugs from past sprints reappear in current sprint, and thus have to re-adress them.

I have a two initial suggestions.

First, I'd take a look at your backlog refinement process. It seems like there's a disconnect between the understanding of the Development Team and Product Owner. The Scrum Guide suggestions that roughly 10% of the total team capacity should be allocated to refinement - in a traditional 40 hour work week and a 1 week Sprint, that's 4 hours per person. Scrum doesn't specify an approach to refinement and leaves it up to the team to determine how it's done.

Next, I'd look at your team's Definition of Done. Make sure that everyone understands what it means for work to be done. Since recurrence of bugs is an issue, I'd look at automated testing as part of the Definition of Done. Not only can you ensure that the initial implementation is correct, you can be more confident that you aren't introducing regressions if you have appropriate automated testing at different levels.

To add to the above, I'd ask whether:

1. During sprint planning, you define and agree to chase a sprint goal. The primary purpose of a sprint is to produce a done, (potentially) releasable, software build, that satisfies the top priorities for the business (as pulled by the development team)

2. You review and order software problems (bugs). Here's something you may find useful. Don't throw all raised bugs into sprint; some may not require a fix until months later - others may require an immediate fix > production patch.

In terms of advice, I'd add:

1. For newly formed teams / teams being introduced to Scrum, I've found 2 weeks or 3 weeks as the most appropriate cycles. 1 week seems too short for me.

2. Look into creating a definition of done for the sprint work (the increment). Quality is of highest concern

3. Look into having clear acceptance criteria for each story. Business requirements will never be perfect. If the work done by the DT satisfies the acceptance criteria, but it's not accepted by PO or stakeholders, and changes are needed, then the outcome isn't a bug, but a new story.

Thank you for your kind and detailed answers.

I'll propose to expand the sprints to 2 week sprints. Suggest removing the daily build review with the whole team. and make better backlog grooming stating specifically the Done criteria for the tasks.

Problem is most of the time the PO and stakeholders cant really foresee these criterias, but we'll try to get to it together as a team.

Some of the fears of making 2 week sprints are that we are not yet good at estimating the effort for the tasks. Sometimes we say 30minute for a task that takes 3 hours and viceversa.

@eugene I actually read that article the other day, thanks for the suggestion.