Skip to main content

Need Clarity around Process Improvements which are part of the Sprint Backlog

Last post 10:13 pm April 7, 2020 by Thomas Owens
2 replies
03:58 pm April 6, 2020

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 based on the above, what I am understanding is that at least one process improvement item must be part of the Sprint Backlog. Correct?

Should this process improvement item be estimated just like the Product Backlog Items selected for the Sprint?

Is this process improvement item also part of meeting the Sprint Goal?

Depending on how work unfolds in the Sprint, I am of the understanding that the Development Team should give priority to meeting the Sprint Goal instead of the process improvement item and as a result my understanding is that completion of the process improvement item is not necessarily mandatory.

What are your thoughts regarding the above?


04:43 pm April 6, 2020

Should this process improvement item be estimated just like the Product Backlog Items selected for the Sprint?

I'd suggest that a team would wish to estimate all of its work, and thereby understand the work remaining to meet the Goal and any other objectives.

Is this process improvement item also part of meeting the Sprint Goal?

Not all of the work a team plans into its Sprint Backlog has to relate to the Sprint Goal:

  • Some items may be essential to Goal realization (e.g. "must haves"),
  • others may not be essential, but nevertheless enhance the value in meeting the Goal (e.g. "should haves"),
  • others may not articulate to the Goal at all but add unrelated value (e.g. "could haves").

This allows a certain degree of scope flex. Process improvement items can also be considered in this light.

Depending on how work unfolds in the Sprint, I am of the understanding that the Development Team should give priority to meeting the Sprint Goal instead of the process improvement item and as a result my understanding is that completion of the process improvement item is not necessarily mandatory.

It could be argued that a process improvement item which does not articulate to the Sprint Goal in some way (e.g. a "must have" or "should have") might not be a timely retrospective choice for the next Sprint.


10:13 pm April 7, 2020

So based on the above, what I am understanding is that at least one process improvement item must be part of the Sprint Backlog. Correct?

Yes. The Sprint Backlog consists of three things - the Product Backlog Items selected for the Sprint, a plan for realizing the Sprint Goal and delivering a Done Increment, and "at least one high priority process improvement identified in the previous Retrospective meeting".

Should this process improvement item be estimated just like the Product Backlog Items selected for the Sprint?

Ultimately, it depends on what the team finds necessary. However, I would consider the process improvement to be a timeboxed effort. I would not spend a lot of time on estimation beyond ensuring that the process improvement that is selected for the Sprint is something that can be implemented over the course of the Sprint. Ideally, it should also be something that is validated over the course of the Sprint to ensure that the change was effective.

Is this process improvement item also part of meeting the Sprint Goal?

I would say no, in most cases. The Sprint Goal should help to focus the team on the most valuable work for the stakeholders. In most cases, I wouldn't expect that the process improvement item would be the most valuable thing for the external stakeholders.

Depending on how work unfolds in the Sprint, I am of the understanding that the Development Team should give priority to meeting the Sprint Goal instead of the process improvement item and as a result my understanding is that completion of the process improvement item is not necessarily mandatory.

I would agree with this. At the same time, however, there does need to be a balance between the team handling internal improvements and delivering value to stakeholders. I'd consider both process improvements and technical debt to be in this category. Neglecting them in favor of delivering value now will reduce or not improve the team's ability to deliver value over time.

I would also add that I don't necessarily agree with the idea that the process improvement comes from "the previous Retrospective meeting". There are a number of reasons for this. Consider a retrospective that generates a number of possible improvements with various impacts. A team only has a limited capacity. Any improvement from a previous retrospective could be more valuable than the most valuable improvement from the most recent retrospective. For this reason, I prefer to think of the idea of a "process improvement backlog" that the team can work through much like the Product Backlog - continuously refining, decomposing, and prioritizing. Depending on the nature of the work, it can be another source of valuable work that the team can draw from when necessary to ensure the members of the team have value-adding work to do.


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.