Skip to main content

Product Backlog is for future releases then Sprint Backlog is about "Done" items

Last post 09:07 pm October 2, 2023 by Daniel Wilhite
15 replies
05:24 pm July 12, 2017

With reference to Scrum Guide, section "Product Backlog"

It states that 

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases."

One can conclude from this statement that Product Backlog is for future releases. What happens to the chosen Product Backlog items when they are turned into a "Done" Increment? Are they moved out of Product Backlog and remain part of the Sprint Backlog?

Should it be concluded that "Sprint Backlog" provides a list of all done items?

Does that mean "Sprint Backlog" is also dynamic and a living artifact?

Or is it that each sprint has its unique "Sprint Backlog" and sum of all "Sprint Backlogs" provide a comprehensive list of of all done items?


09:46 pm July 12, 2017

From the Scrum Guide:


The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. 

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint... As new work is required, the Development Team adds it to the Sprint Backlog. 



03:12 am July 13, 2017

Thanks Timothy. If you could clear my doubt about following two questions, I will really appreciate it.

1. What happens to "Product Backlog" items that has been declared "Done" after, say, just now concluded Sprint? Are they taken out of "Product Backlog"? If yes, then how these done items log are maintained in the Scrum?

2. It is clear that each sprint has its unique "Sprint Backlog". So is it that sum of all "Sprint Backlogs" provide a comprehensive list of of all done items? Saying so, implies that, each Sprint Backlog might have been maintained for historical purpose.

06:17 am July 13, 2017

The Product Backlog is the single repository where the requirements, features, changes, etc.. are documented and prioritised.

Sprint Backlog is the subset of the Product Backlog which shows the current state of In progress work and eventually Done.

To answer your question what happens to done, its very similar to maintaining the status of each requirement . In your Product Backlog either you have a column to state its Done after sprint review for the items accepted, create a separate section in your repository (sheet in excel, table in word. etc..) to track the Done items.


05:08 pm July 13, 2017

Who would need that "log" of completed backlog items, and for what "historical purpose" would they use it? 

09:33 am July 14, 2017

The Scrum Team, because, Scrum is based on Empiricism. 

Would not the Scrum team or teams in an organization like to inspect and adapt based on the historical data of other successful projects/products?

09:44 am July 14, 2017

If Product Backlog also keeps done items then may be the statement in Scrum Guide that states 

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases."

need modification to reflect the reality, that, it contains Done items and future requirements both.


01:07 pm July 14, 2017

Manoj, the Product Backlog should never contain "Done" items.   The Product Backlog doesn't even contain active sprint items.   Those PBI's are moved to and reside in the Sprint Backlog once they are accepted by the team for the sprint.


Perhaps it would be easier to think of a Product Backlog as a long "to do" list, and a Sprint Backlog as a "do now" list.   Can items exist in both places?   Should they?   When items are completed and crossed off of the "do now" list, do they return to the "to do" list?   What is gained by maintaining both open and completed items in your "to do" list?


When an item is completed in a sprint, it is up to the team/organization how they want to maintain that information going forward, but it is never returned to the Product Backlog.

01:32 pm July 14, 2017

Sounds great. Thank you so much, Timothy.

04:04 pm July 14, 2017

Empiricism is based on the evidence of value delivered, not on a log of Product Backlog items or other proxy measure. 

06:00 pm July 14, 2017

That also depends on what attributes someone define in Product Backlog.

I was going through "A Lightweight Guide to the Theory and Practice of Scrum Version 2.0". In this small document on Page 6, figure 2, there is a sample "Product Backlog".

It shows that Product Backlog might define "Initial Size Estimate". Similarly, if in Sprint Backlog the actual size required to implement a feature is kept, then would not this data along with other factors like skills (technical and/or functional) of the Development team becomes "Empirical Process Control" or "Ëmpiricism" (Empiricism asserts that knowledge comes from experience and making decisions based on what is known.). 


07:05 pm July 14, 2017

No, because estimates and other useful information should always be kept up-to-date, and inspection and adaptation ought to be as timely as possible. Hence there are only three artifacts in Scrum...the Product Backlog, the Sprint Backlog, and the Increment. Logs would be untimely for the purposes of empirical process control and hence are not part of the framework. 

01:20 pm July 15, 2017

Thanks a lot Ian. I learned a lot from this discussion.

08:50 pm September 29, 2023

A Scrum project is planned to have two releases, one of the middle and the other at the end of the project. What will happen?

06:07 pm October 2, 2023

Hopefully a Scrum Master will explain that the most important project is the Sprint, because that's the one which allows empiricism to be established and maintained. Any number of releases might be made.

09:07 pm October 2, 2023

Well, I would assume that there would be a release in the middle of the project and one at the end of the project.  However, I am not entirely sure what you mean by a "Scrum project", especially one that has seems to already have planned out all of the necessary iterations.  That seems more like a waterfall project that wants to use some Scrum terminology. 

In an environment that is utilizing the Scrum framework, releases can occur anytime and as seldom/often as desired.  The focus isn't on a release, but it is on the creation of one or more usable increments of value in every Sprint. My normal coaching is that each increment is of release quality and integrated with all previous increments so that an increment can be released at any time. As discussed above, because of the empirical nature of Scrum, each Sprint will also provide new information about what is and should be built into the Product. 

Now, let me turn your question around.  What do you expect will happen? Why does it only make sense to release twice? How long is this "Scrum project" expected to last?

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.