Estimate retro action items
Hello
I am on a scrum team and we are ‘tracking’ improvement action items from our retrospectives on the product backlog so they are visible. We add them at the end of the retro to the product backlog and usually in sprint planning add to the sprint backlog. We have not been estimating them (we generally estimate other pbi’s during refinement - we use story points) and one of the developers asked recently why are we not estimating the retro action items? had not come across this before so I am curious if other teams estimate these items and what your thoughts are?
Is the team able to improve? That is, at Sprint Planning, is the team able to craft a Sprint Goal, build a Sprint Backlog, and come up with an achievable plan for meeting the Sprint Goal, while leaving enough time for refinement and these improvement items?
The primary purpose of the estimates is to help a team plan their Sprint. As long as the team is able to plan their Sprints and regularly meet their Sprint Goals and improve their way of working, it's probably fine. If estimating these improvement items would improve the team's ability to plan out a Sprint, then maybe it's worth looking into.
I am on a scrum team and we are ‘tracking’ improvement action items from our retrospectives on the product backlog so they are visible.
Does the team really want the Product Owner managing these items and ordering them?
In the current edition of the Scrum Guide it states this:
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
Notice it mentions adding them to the Sprint Backlog not the Product Backlog. According to the Scrum Guide, 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.
Are these improvement actions identified in the Sprint Retrospective needed to improve the product? If not, why are they being added to the Product Backlog? And how often are the ones added to the Product Backlog deferred in favor of work to add functionality to the Product?
In my experience it is best to track them in the very next Sprint Backlog if the action was deemed important enough to implement. And they usually aren't the type of activity that requires dedicated time by a developer but more of activities that need to be kept "top of mind" while the team works.