Skip to main content

Question (not refined Product Backlog, Sprint planning)?

Last post 11:12 am February 4, 2020 by Harshal Rathee
6 replies
10:52 pm April 22, 2014

Q1:
How should we react if we realize at Sprint Planning Meeting that the prodcut backlog is not enough refined (clear)? It has impact on Dev Team's forcasting. for sure the PO must be coach to prevent such situation for future sprints. I can imagine following 3 ways:

A) We postpone the Planning meeting until we get first clarity for the top PBI in an extra refinement session because these are the most valuable Items and are important to be implemented first.

B) we keep the sprint planning meeting as planned and the Dev. team forcast roughly despite these ambiguities; and they adjust the scope (commited work) if necessary later during sprint with PO agreement

C) to remark such PBI on the top of Product Backlog list as "not ready" and ignore them for the current sprint . The dev. team pulls only PBI which are ready.

------------------------------------------------------------------

Q2: Do you use similar to DoD , DoR (Definition of Ready) in your project for PBI ?
If yes, could you please share your DoR ?

Thanks,
Mehdi


04:42 am April 23, 2014

If the Product Backlog is not in a fit state for Sprint Planning, then the Sprint cannot commence. Since a Sprint is a container for the other Scrum events, this means that those events cannot be held at all.

What the team need to do is to refine the Product Backlog so that it is fit for purpose and a Sprint can start. This is more or less the "option A" you refer to, but it isn't really a matter of postponing Sprint Planning in particular. The fact is that no Scrum events at all can occur until then.


10:09 am April 23, 2014

Hi Mehdi,
Q1: From the perspective of an Agile Coach, it is important to let the team fail here, so they will learn more likely than if you save them from failing and give them the chance to wait and prepare. Especially the Product Owner, who is accountable for backlog management, has to see during the sprint planning and the sprint how much waste he generates by not doing his job. The Coach should mainly observe. Then in the retrospective you can take all these observations and improve for the next sprint. A whole sprint seems like a big investion just to learn something, but the Product Owner will not come to a planning without a well prepared backlog again. I guess this is a combination of B and C.

Q2: We use a DoD, which is really important. I know some teams use an explicit DoR, however for us a PBI is ready if the team is able to estimate it, so we do not have this definition explicitly. I think it is hard to write it down specifically, but the INVEST criteria give you an orientation (independent, negotiable, valuable, estimable, small, testable).


09:31 am September 10, 2014

Q1 - C
If you try to plan what is not ready, this can repeat itself.
Since you mention there are other PBIs in ready state, those should be taken to the sprint.


08:37 am February 3, 2020

Hi Ian,

refer to scrum guide, new Sprint starts immediately after the conclusion of previous sprint.

Would Option B is likely the more appropriate approach to start the next sprint where the team will adjust and refine the spite backlog ?


06:46 pm February 3, 2020

With 6 years hindsight I’d go for option C.


11:12 am February 4, 2020

A) We postpone the Planning meeting until we get first clarity for the top PBI in an extra refinement session because these are the most valuable Items and are important to be implemented first.

B) we keep the sprint planning meeting as planned and the Dev. team forcast roughly despite these ambiguities; and they adjust the scope (committed work) if necessary later during sprint with PO agreement

C) to remark such PBI on the top of Product Backlog list as "not ready" and ignore them for the current sprint . The dev. team pulls only PBI which are ready.

I think it can be situational , and as per me would go in this order - 

1. Choose option C and take this PBI into next sprint when refined.

2. Continue planning for other PBIs and if time box for planning still allows then will continue to refine this important PBI.

3. Choose A - Only in worst situation when no value can be delivered in a Sprint without implementing these unrefined PBIs. But as @Ian mentioned no further events can take place until then.


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.