Planning for scrum - need advice

Last post 11:33 am May 7, 2021
by Ryan Kent
4 replies
11:41 am March 15, 2017

We are a young scrum team and in the process of making things work. At planning, the product owner provides a list of user stories arranged by priority, highest on top. 
We believe we shall estimate the time needed for the user stories as long as availability lasts. The product owner, however, requires that we estimate all the user stories given, although there is no availability; then he may eventually re-arrange some of the user stories by value and re-arrange the priorities. The unprocessed user stories remain for the next planning. Then we need to estimate the availability from scratch. 

What is your experience with this? How would you act in such situation?

02:38 pm March 15, 2017

In Scrum, the Product Backlog MUST be estimated (remember DEEP for : Detail appropriatly ; Estimated ; Emergent ; Prioritized).

But, you can provide coarsed-grained estimates in a few minutes.

06:50 pm March 15, 2017

The team can quickly sort story cards by means of relative sizing, and thus give a rough estimate for all product backlog items.

02:08 pm May 6, 2021

The PO has to sort the PBL. Sorting the PBL can be done on several values.

For example, if he got a list of 10 stories, with a very high importance for the next sprint, he will put those at the top. But when you estimate, it could happen that with the estimation he sees, that you cannot do all 10 stories. So given the first four have high estimates, shall he only take those 4 or could he get 6 stories in, if he changed a huge story against two small stories. 

Besides the pure number of stories, which should not be the criteria to sort, he should also consider cost-benefits, which might be better with a smaller story.

11:33 am May 7, 2021



I think we should be careful in saying “In Scrum, the Product Backlog MUST be estimated”. “Must” is only mentioned 11 times in the 2020 guide, and it doesn’t land anywhere near the topic of estimates.


As per 2020 version, language has changed to suggest sizing instead of estimating. Size is even only mentioned in a list that follows “such as” with a call out that attributes often vary with the domain of work.


Some teams may be following #noestimates approach, some may use colour coded stickies to indicate size or complexity or whatever helps their PO in ordering decisions. Some will also find value in your suggestion.


This is ultimately left up to the team to decide what is best.