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

Last post 01:20 pm July 15, 2017
by Manoj Tiwari
12 replies
Author
Messages
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.