Skip to main content

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

Last post 11:00 pm December 28, 2022 by Ian Mitchell
28 replies
05:59 pm March 3, 2019

Question: TRUE or FALSE: The Scrum Team should choose at least one high priority process improvement, identified during the Sprint Retrospective, and place it in the Product Backlog.

My answer: TRUE

Actual Answer: False, to ensure continuous improvement, the Sprint Backlog rather than the Product Backlog includes at least one high priority process improvement identified in the previous Sprint Retrospective meeting.

Now, this is really tricky. The Sprint backlog is created during Sprint Planning and the items to be taken for the Sprint Backlog would come only from a Product Backlog, isn't it? So, during (or at end of) the Sprint Retrospective, the "high priority process improvement" item(s) should be placed in the product backlog by the PO who's part of Scrum Team. During the Sprint Planning, the "high priority process improvement" item can be picked from the Product backlog by the Scrum Team. That's my take. What's your take on the question and the answer?

Thanks for your time!

Regards,

SU

 


03:07 pm March 4, 2019

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


05:36 pm March 4, 2019

Sandeep,

From what source did your question come from?


06:52 pm March 4, 2019

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?


10:09 pm March 4, 2019

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. 

 


09:45 am March 15, 2019

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.


09:15 pm March 22, 2019

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.

 

 

   


03:08 pm July 24, 2020

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


01:23 am July 25, 2020

@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.

 

 


06:49 pm August 14, 2020

@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. 


07:23 pm August 14, 2020

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?


07:40 am August 15, 2020

@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?


10:51 am September 6, 2020

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.


05:25 pm April 7, 2021

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.


07:10 pm April 7, 2021

@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...


01:30 am April 8, 2021

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.


03:14 am April 8, 2021

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

 


05:55 am April 8, 2021

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


11:49 pm August 31, 2021

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?


01:20 pm September 1, 2021

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.  


03:58 pm November 16, 2021

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.


12:28 am February 9, 2022

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

 


02:11 pm February 14, 2022

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.


07:27 pm October 11, 2022

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.


11:21 am November 8, 2022

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 


06:49 pm December 28, 2022

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.


09:53 pm December 28, 2022

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.


10:21 pm December 28, 2022

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)?


11:00 pm December 28, 2022

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.