TL;DR: Once a story is completed, the team needs feedback on it. This can be done as stories are completed, or the team can receive feedback during the Review Meeting. The sooner, the better.
During Sprint Planning, the team decides what user stories and product backlog items to pull into the sprint. They choose on what they will be working on from the items ...
I encourage the teams I work with to show their development work to the Product Owner throughout the sprint. This makes the need to have a Product Owner review at the end less important.
It also helps to reduce the frequency of requirement misunderstandings.
It's not clear to me if you are referring to the Sprint backlog or to the Product Backlog so I'll add an answer for both.
For the Product Backlog
Create two epics called "Refactoring" and "Technical debt" (or any other large category of work you find necessary). Don't add any stories to the epics. Instead, add all the development tasks as ...
This problem isn't unique to Scrum. It's quite common across the Agile methods, which call for frequent delivery of valuable, working software to customers and users. I've come across two ways to handle this situation, both of which have worked out well.
The first way would be to define the infrastructure that is needed as part of both A and B. Then, ...
(Too large for a comment)
I disagree with two of your remarks under point 1:
"The infra itself has no customer value." So, get rid of the rigid requirement that "These stories are supposed to be customer oriented and deliver value.", change it to "These stories are supposed to deliver value".
"The backlog now contains ...
Backlog should contain all workable items
According to Scrum Guide:
Product Backlog is the single source of work undertaken by the Scrum Team.
So in my opinion the Backlog should contain all workable items including but not limited to:
user stories from all your stakeholders
this is business functionality
risk mitigation items
eg. when we need to do ...
The 2020 Scrum Guide says:
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Most of the thinking that I've seen has been that the work in the Product Backlog should be something that adds value to the customers and users of the product and that tasks ...
In my opinion, "backlog" is an unfortunate choice of terminology, because what we should be referring-to here is not really a "backlog" at all – in the human sense of "falling behind."
Apple uses an internal management system they call RADAR, and there are (or, used to be) posters on the walls(!) which said: "Put it on the ...
I generally agree with Ashok's post above, but I find that in actual practice a "task-based view" and a "story-based view" often exist side-by-side, and that "tasks" are not strictly tied to "stories." Because they don't have to be.
I find that "a 'user story' is exactly that: an expression from a hypothetical-...
In Scrum, backlog is a list of outstanding user stories
You are using the terms backlog, user stories and sprint. So, I will answer this in the context of Scrum. Scrum is recommended for projects, such as software development, where requirements can change late in the cycle and technology could throw some unpredictable challenges.
Let us say that you want to ...