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

Last post 05:55 am April 8, 2021
by Scott Anthony Keatinge
17 replies
Author
Messages
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