product backlogs items VS sprint backlog items

You are right, usually pbis are split and get smaller over time before they reach the sprint backlog, so generally speaking sprint backlog items are smaller than product backlog items.
However, I have also made the experience that during backlog refinement we have split a story in two, and in sprint planning the dev team fastened them together again with a stapler.
You never know.

A Sprint Backlog Item can be seen as a Product Backlog Item plus a plan for implementing it. In that sense it is additive to, and thus "larger" than, the selected PBI.

The truth is that the two backlogs serve different purposes, and the items within are not directly comparable.

I really don't understand that question ... What is the "item size" ?

Each PBI has to be estimated by the dev team. Item size refers to that estimate.

I have simple example 3 top PBIs is A,B,C now. In refinement meeting we split A, B into A1, A2, B1, B2, B3 and see that we can only pick A1, A2, B1, B2 for next sprint. At that time all A1, A2, B1, B2, B3, C,....is PBIs but in next sprint A1, A2, B1, B2 will become SPBIs. So you can consider SPBI small as PBI (if compare with B3) or smaller PBI (if compare with C).

Anyway I think item size in this question should be understand by relative way (e.g. Item type) and should not by absolute estimation (in hours) because every item always take different time to finished it.

Thanks,

The Scrum Guide says at page 12 & 14:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements.

The Sprint Backlog is a forecast (…) what functionality will be in the next Increment and the work needed to deliver that functionality. The Sprint Backlog makes visible all of the work (…) The Sprint Backlog is a plan (…)

End quotes.

===

So, the Product Backlog and the Sprint Backlog are defined, but an exact definition of PBI’s and SPI’s are not given.

However it is commonly accepted that a PB can contain User Stories and SP contains tasks.

===

So for example a User Story can say: “As a telesell company manager, I want the customer to be able to change it’s preferences by himself, in order to reduce my operational costs.”

This requirement can lead to multiple demanding tasks like: setting up a database, defining a user interface, providing for a secure communication channel, etc.

In this example, the User Story could be written down in 5 minutes, where the tasks may take a complete sprint. In this regard, the tasks are much bigger than the requirement.

However, from the business point of view, the individual tasks and results have no individual value. So the requirement of the User Story is much bigger.

===

Hmmm, only now I see the original post was not recent. I submit this answer anyway for anyone that is interested.

Dear Ian, based on your explanation, the following answer in the Mgmt Plaza practice exam is incorrect, right?

1. Question

Items in the Product Backlog are usually larger than items in the Sprint Backlogs.

•  True

This is how it works:

1. Items of different sizes are added to the Product Backlog.
2. Items are sorted based on their business value.
3. Then we check the items on the top of the Product Backlog, and if they are large, we’ll break them down into smaller items. We leave the large items on the bottom of the Product Backlog as they are for now.
4. The business values will be estimated again, and the Product Backlog sorted based on them.

Based on this explanation, the items on the top of the Product Backlog would be, statistically speaking, smaller than the average. Since the items in the Sprint Backlog come from the top of the Product Backlog, we can say that “the items in the Sprint Backlog are usually smaller than the average item in the Product Backlog”.

Remember that we sort the Product Backlog items based only on their business value. The difference in size happens naturally, and is not a basis for sorting.

In my view the correct answer would default to false, given that the means of comparison is not elucidated. Refinement can indeed usually be expected to reduce items in their estimated size, but more detail will usually be added. Sprint Planning will add even more detail in terms of a plan for implementation.

Dear friends, I am newbie in this scrum related knowledge. Before we start our first SPRINT , should we have mapped all the Product Backlog item, into all SPRINTS that we planned? So that in overall we will know how many SPRINTs that we should execute as early as possibble just after create Product Backlog, and what is the Product Backlog items that must be included in which SPRINT. As of now, i always got the impression that  at a time, we only develop one SPRINT just before that specific SPRINT is executed.  (The product backlog items that need to be complete in a SPRINT X+1 should be provided only at the time SPRINT X finished) Please correct me if i am wrong, and kindly advise.

Zak, I may have misunderstood your question, I apologise if the below isn't what you were asking for:

The purpose of your Product Backlog is to contain all of the PBIs known to be needed to improve the product (these may include things like features, addressing technical debt, security fixes, bugs etc) but the most important thing to know is that it is emergent - it will grow/reduce as work is identified or done, all you need for Sprint 1 is a goal to achieve, a group of developers to achieve it, and a plan for how to do it.

Mapping PBIs into future Sprints may not the best idea (but some context would help here), especially if this is something you will show to stakeholders - there is a risk this could start to look like a delivery plan and a time-based commitment. However, if it's internal to improve transparency for the Scrum Team in terms of complementary release planning or similar, then you can use whatever works for you. Just be careful of it looking and feeling like an inflexible commitment - adaptability is your friend :). The commitment for the Product Backlog is the Product Goal. Scrum is based on an empirical framework, and so the plan for upcoming and inflight Sprints will (and often should) change so that you can be more likely to and meet your Sprint Goal (or create achievable ones).

In order to minimise waste, it's common for Scrum Teams to use Product Backlog Refinement to decompose likely Sprint candidates, perhaps working one/two Sprints ahead. Much more than that may potentially mean you spend time refining PBIs that will never be required. I tend to coach team on the 'just in time' principle. In that that case, mapping PBIs to future Sprints becomes hard, as we haven't had the evidence to tell what we need to do yet.

I hope this helps. If I got the wrong end of the stick, let me know and I'll clarify :).

should we have mapped all the Product Backlog item, into all SPRINTS that we planned

That is exactly what a waterfall project plan would do.  But it removes all inspect and adapt capabilities that are the premise of agile and Scrum.  Plan one Sprint at a time and take into account the learnings from the previous Sprint.  

Will you know how many Sprints it will take?  No, but in the end the stakeholder will get what they want at they time they want it instead of what they wanted when they first talked to you.  And it could be less than what they originally asked.  There are times that by iteratively working on the solution and sharing the progress with the stakeholders in every Sprint, you will be able to get to a solution in less time than you would think.  It can also take longer but because the stakeholders are involved it is easier for them to understand and you are delivering working software as you go. 

As of now, i always got the impression that  at a time, we only develop one SPRINT just before that specific SPRINT is executed.  (The product backlog items that need to be complete in a SPRINT X+1 should be provided only at the time SPRINT X finished) 

You are correct in that impression. 

Thank you,  Daniel and Ryan. Your explanation is enlightening me.

Previously, this is one of my primary confusion because from the material that i have read so far, there is no clear information about how many SPRINTs (with selected user stories that should be mapped into respective SPRINTs) that we need to have in advanced at the start of an AGILE project.

From all of your explanation, it seems that there is no specific rule about it, but knowing the essence of AGILE approach, we don't need to have complete SPRINT roadmap at the beginning of the project.

Thus, we dont need to have estimate total number of SPRINTs, and which PBIs to be mapped in the SPRINT-1, SPRINT-2...till SPRINT-N at the beginning.

I assume that at a time, we may need to have a list of PBIs that have been mapped only to the current SPRINT and next 1 SPRINT ahead.

I hope my understanding is right.

Thank you.