Where is the "high priority process improvement" identified during Sprint Retrospective placed?

Sprint backlog is the outcome of the sprint planning meeting. In certain cases some important stories may be exluded to be taken into the actual sprint for different reasons therefore, from this point of view SB is the actual work that the team forecast for the ongoing sprint. I believe that is most likely the reasoning behind the answer. Albeit, it does makes sense what you are suggesting, story will be worked on only when its taken into sprint planning. This is also term known as Scrumming the Scrum

Sandeep,

From what source did your question come from?

the items to be taken for the Sprint Backlog would come only from a Product Backlog, isn't it?

Why do you think so? Would items from a Product Backlog adequately capture the Development Team’s plan of work for the Sprint?

A few excerpts from the Scrum Guide

A new Sprint starts immediately after the conclusion of the previous Sprint.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. 

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. 

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

Yes, I pulled some random excerpts but they support my interpretation.  I see the Review as the end of a Sprint.  Immediately following the Review, a new Sprint starts.  Since the Retrospective occurs after the Review and before Planning, you already have a Sprint started.  So why can't the improvement item be brought directly into the Sprint Backlog if the Scrum Team has decided that is something that they want to work on during the Sprint?

So, I answered this with some Scrum Guide quotes.  Now, let me point out something else. 

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.

Is the identified improvement something that is needed to implement the Sprint Goal?  If not, why is it in the Sprint Backlog at all?  I usually just write the selected improvement(s) on large sticky notes and put them on the wall beside our physical board for everyone to see.

As with all things discussed here, I will say there is no right answer. This is only my opinion and you should take it as something to consider and then do what your team feels is best. 

All,

I thank you for your inputs!

Took a break, stepped back and looked again.

For the Sprint Retrospective, the Scrum Guide says -

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

And then, for the Sprint Backlog, it says - 

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

So, it nowhere says that these identified improvements (during the Sprint Retrospective) should be placed it the Product backlog. They just need to be identified. Some Scrum teams may maintain those on sticky notes, some will maintain them in retrospective meeting notes, some will choose to maintain them in Product Backlog, some will maintain them somewhere else (may be a "Process Improvements Backlog"). So I think it's kept quite open, what they want to do as far as maintaining them is concerned. However, when it comes to making use of them, one of the high priority process improvements is chosen and placed in the Sprint Backlog.

It was a good exercise for me. I thank the forum members again who shared their perspective.

The conflict here lays in the lack of clear explanation.

If you put the improvement your team found in the sprint retro in the sprint backlog, (wish is at the end of the sprint).

and then the sprint is over.

What happens with the remaining task that are not done?

You just don't add them automatically to the next sprint by leaving them in the sprint backlog!

The improvement your team found will be just like the other not done tasks, they will be put back to the product backlog at the end of the sprint. 

The most logical thing to do will be to put the improvement task directly in the product backlog on top of the list.

Other ways the task with the improvement will be the only thing left on the sprint backlog, to be transferred to the new sprint backlog.

But this explanation does not exist anywhere.

In the guide, it says:

At the end of the Sprint Retrospective, the Scrum Team should have identified improvements that will be implemented in the next Sprint. The implementation of these improvements in the next Sprint is the form of adaptation to the inspection that the Scrum team does with itself.



This Guide item in "Sprint Retrospective" talks about getting an improvement that the "team" should apply in the next sprint for the "process" .... for example: Greater commitment to the daily or getting fewer stories within the next sprint and etc ....



The test question would focus on a business item that will be developed in the next sprint, but falls into disbelief because the Sprint Retrospective is a "team alignment" event and not an entry into the business.



I see this as just a "joke" from the scrum test. LoL

@Daniel, the question at the top of this thread is false and is directly from the Scrum Guide: "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting."  So the Product Backlog is incorrect, the correct answer is the Sprint Backlog. 

This was added in the 2017 release because if you leave process improvement items up to the Product Backlog and the Product Owner, they will almost always choose work items over process improvement focused on product delivery.  If we add 1 item to the Sprint Backlog directly to ensure that the team is always looking for ways to improve, this will help them prioritize that improvement and not lower the priority of the item by the Product Owner for example or other work.  It is at the heart of empiricism.

@Eric, I Agree with your statement. when there are two process improvement found in a Sprint Retrospective if the sprint backlog can accommodate only one high priority process improvement due to the other product priority tasks. So where the other process improvement will be placed. 

So where the other process improvement will be placed. 

Should the team archive low priority process improvements at all, or focus on ensuring that high priority improvements are identified and implemented in a timely manner?

@Ian, It doesn't mean the low priority improvement task shouldn't take into an account, since every opportunity of improvement is a necessary part of empiricism. I mean in the context of; Is the low priority improvement task get placed on the "product backlog" or "sprint backlog" on this scenario?

I completely agree with @Eric.

@Jagath, It is again up to the team itself on deciding what to include in the Sprint. Most often the process improvement tasks are not explicitly time taking, they are usually changes need to be brought in for better and improved team as a unit committed to deliver more in the same time, changes in personal behavior, changes related to estimation technique etc. So more than one process improvement tasks could be taken up in a sprint without sacrificing on the value based tasks. But off course the Product Owner has to be put in confidence that even if one of the value tasks are being dropped for now, it would certainly increase and improve the team capacity in future to take on two or even more such tasks in a sprint resulting in more self-organized, self-managed and process adhering team at your disposal.

An earlier version of the Scrum Guide prescribed the practice of placing one improvement in the Sprint Backlog. This was removed in the 2020 update to the Scrum Guide because it was felt to be too prescriptive. However, if this practice provides value to you then you should adopt it. It is simply not prescribed anymore, but can still be valuable.

@Pau, having talked to Ken about that, you hit the nail on the head.  He added it originally because he felt that it was too easy for a PO to ignore the process improvement and focus only on features, so making it mandatory felt right.  After feedback, it was moved to Product Backlog to give the whole team visibility and allowing the whole team to decide if it should move into a Sprint.  Less prescriptive...

If I understand correctly, according to the new guide 2020, during restrospective, a team can identify for example 3 improvements. They then place them in the Product Backlog. Then at one point, during planning for Sprint X, they can pick the top priority improvement and put it in the Sprint Backlog?

On a side note, a product backlog doesn't only contain "product" related items but also things like improvements, which is more "team" related items.

If I understand correctly, according to the new guide 2020, during restrospective, a team can identify for example 3 improvements. They then place them in the Product Backlog. Then at one point, during planning for Sprint X, they can pick the top priority improvement and put it in the Sprint Backlog?

I would say so if you can achieve the sprint goal and do 3 improvement items in the same sprint. I would suggest we should identify one item or the most helpful changes to help your team improve. As practitioners we can't achieve any improvement for the first time, we may have to bring the improvement item back to retrospective again to discuss what would be changed to make the action better for the next try. 

For the main point, again I would say YES if we can achieve the sprint goal and 3 improvement items at the same time.

Just my 2 cents

 

If I understand correctly, according to the new guide 2020, during restrospective, a team can identify for example 3 improvements. They then place them in the Product Backlog. Then at one point, during planning for Sprint X, they can pick the top priority improvement and put it in the Sprint Backlog?

On a side note, a product backlog doesn't only contain "product" related items but also things like improvements, which is more "team" related items.

Correct

After feedback, it was moved to Product Backlog to give the whole team visibility and allowing the whole team to decide if it should move into a Sprint.  Less prescriptive...

@Eric Naiburg, Two questions:

1. To clarify, is it the Sprint Backlog or the Product Backlog?

2. If it is indeed the Product Backlog, then would an improvement item that has no direct relation to the Product still be captured there?

Hello @Steve:

1. Per the Scrum Guide "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."  So items are moved to the Product Backlog and if deemed to be accomplished during the Sprint, the Sprint Backlog.

2. That doesn't mean you wouldn't add other items to the Product Backlog to capture, prioritize, etc.  Team improvements do have direct relation to the product as they are related to how the team delivering the product works and how they will work to deliver the product.  

As per Scrum Guide 2020 below things are said,

Sprint Retrospective

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.

@Vijaykumar, as soon as possible, whatever self-managed team is deemed appropriate.

It depends on priority of identified improvement item in comparison of sprint backlog items, capacity of team for subsequent sprint and maturity of scrum team - whether its forming, storming, norming, performing, feasibility of item.

It is simply and clearly stated in Scrum Guide 2020 

The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

Ladies and Gentlemen, I see something different from the question. The one high-priority process improvement from the previous Retrospective is NOT placed on Product Backlog but Sprint backlog item, hence, It is FALSE. Simple 

IMPO, unless the "Impactful Improvement" is technical in nature - for example, the implementation of say GitHub, BitBucket, Jenkins, Ansible Tower, etc, into the process, then it is NOT something that should be an item in the Backlog as it is not "work" that can be done/estimated.  It would just be another "agreed upon" Team process of "how to do something".  Additionally, there is nothing stating that it "should" or "must" be in the "next Sprint" - even if a "high-priority" Tech PI is agreed to be implemented, it would go into the PRODUCT Backlog, but not necessarily the Sprint Backlog, unless the Developers were actually able to do something with it - therefore, it would be entirely conditional.

Finally, to re-iterate the quotation above from the 2020 Guide, the key words are "addressed as soon as possible" and "may even".

I look forward to everyone's thoughts :)

Thank you.

IMPO, unless the "Impactful Improvement" is technical in nature - for example, the implementation of say GitHub, BitBucket, Jenkins, Ansible Tower, etc, into the process, then it is NOT something that should be an item in the Backlog as it is not "work" that can be done/estimated. 

Going out for a team lunch or curry night can be an impactful improvement; it can also be Done (tables booked, transport sorted, money taken) and estimated (1-2 hours of everyone's time). They may even plan this work in the Sprint Backlog if they reckon it's the best way to ensure things actually happen.

IMPO, unless the "Impactful Improvement" is technical in nature - for example, the implementation of say GitHub, BitBucket, Jenkins, Ansible Tower, etc, into the process, then it is NOT something that should be an item in the Backlog as it is not "work" that can be done/estimated. 

Going out for a team lunch or curry night can be an impactful improvement; it can also be Done (tables booked, transport sorted, money taken) and estimated (1-2 hours of everyone's time). They may even plan this work in the Sprint Backlog if they reckon it's the best way to ensure things actually happen.

I suppose there is a position to be made there - I'd not considered that angle, though honestly, I've not encountered a team that did anything like that.  Though, if one were to follow that logic, then wouldn't all the Scrum Ceremonies/Events (as well as any other meetings, BAU or not) also be Backlog Items (to maintain consistency)?

If they find such "consistency" helpful when meeting their commitments, then perhaps, yes.