Skip to main content

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

Olivier,

 

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.


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.