Skip to main content

Question on Product Backlog Refinement

Last post 09:15 am November 8, 2019 by Vikas Mehrotra
13 replies
09:13 am November 1, 2019

I need opinion from Scrum SMEs and practitioners on the below question:

Product backlog refinement…

a) Must be completed before the sprint 1

b) Can be done during the sprint planning

c) Can be done during the sprint review

d) Must be done only during the sprint

e) Must be done only between the sprints

f) Must be done along with sprint backlog refinement

g) Can be done during sprint retrospective

h) Must be attended by PO and dev team

IMO the answer must be b, c, d, g, h since all the events do touch the product backlog. 'h' is obvious when the refinement session happens during the sprint. 'd' is correct since all events are part of sprint only. 


12:30 pm November 1, 2019

This doesn't seem like a very well thought out question. I'm also assuming it's not from Scrum.org. 

If I had to give an answer I would argue d) Must be done only during the sprint

The Sprint is the container that holds all of the Scrum events, which would include Backlog Refinement. 


08:01 pm November 1, 2019

Could the future scrum team not meet and refine the backlog before the first sprint and the first planing? 

And what is the difference between sprint backlog refinement and backlog refinement?


09:46 pm November 1, 2019

To echo Tony's sentiments, this is a very poorly-worded question.

That said, I cannot resist looking at each option, and not only identifying why it might be right, but also identifying why it may be wrong.   Thank you for indulging me, and please feel free to address any of my opinions/statements that may be incorrect.

a) Before Sprint 1.   This implies that there is a period before the first sprint, which Scrum does not recognize.   The only requirement is that each sprint deliver something that is usable and potentially-releasable.   Can this be done without refining items beforehand?   Can the team forecast functionality to be delivered in the first sprint without conducting pre-first sprint refinement?   I think so, so my answer would be No

 

b) During Sprint Planning.   This should be the exception rather than the rule, since it implies that non-ready items are being presented/discussed in Sprint Planning.   This could be the case if items are identified in the Sprint Review for the next sprint.   Scrum does not prohibit this.   My answer would be Yes

 

c) During Sprint Review.   You may adjust the Product Backlog based on Sprint Review feedback/discussions, but IMO you would not refine any items in a Sprint Review.   Any refinement, estimation, or forecast would therefore take place in Sprint Planning    My answer would be No

 

d) During Sprint.   Since there never is a point in time when a sprint is not active, my answer would be Yes

 

e) Between Sprints.   Since there is no such thing (between the sprints), my answer would be No

 

f) With Sprint Backlog Refinement.   Since there is no such thing as Sprint Backlog Refinement in Scrum, my answer would be No

 

g) During Sprint Retrospective.   Since the only item from a Sprint Retrospective that can find its way to a Sprint Backlog is a Kaizen, and since Kaizens are improvements/experiments that do not require refinement, my answer would be No

 

h) Between PO and Dev Team.   Since refinement activities are identified in the Scrum Guide as a collaboration between the PO and the Development Team, my answer would be Yes


10:41 am November 5, 2019

I agree that this is a poorly worded question, but it was being prepared for a quiz and that's why I requested the experts opinions. @Timothy Baffa and others - thanks for detailed explanations.

for option c) --- What exactly is meant by adjustment? The product backlog has items, and they have some attributes, if the attributes are changed, are we not refining them in some way for better understanding of the intended audience?

for option g) --- the scrum guide mentions --- "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting."   --- the one item identified is put where? in Product backlog only right? Since the current sprint is ending and the next one can be created from the product backlog in the next sprint planning planning meeting.If the item is not put in product backlog where do we maintain it?

I may be thinking too much. Please help.

thanks

V.


12:44 pm November 5, 2019

for option c) --- What exactly is meant by adjustment? The product backlog has items, and they have some attributes, if the attributes are changed, are we not refining them in some way for better understanding of the intended audience?

Refinement doesn't always have to be such a formal event and could happen ad hoc at any time. I would just caution against detracting from the purpose of other events should this happen. My thoughts around the Sprint Review is that if the group is inspecting a 'Done' increment then feedback may be added as a PBI to be refined now or later (the former could take the group away from the purpose of the Review though). 

 

the one item identified is put where?

I believe the Scrum Guide addresses this and the retro action item is to be put in the Sprint Backlog for the upcoming Sprint as it is an item for the Development Team to improve upon. 


01:08 pm November 5, 2019

Here's my $0.02,and I seem to disagree with Timothy on b), g) and h).

The only thing the S.G. seems to specify on refinement:

Product Backlog Refinement = adding detail, estimates, and order to items in the Product Backlog. (...)

The Product Owner and the Development Team collaborate on the details of Product Backlog items. (...)

The Scrum Team decides how and when refinement is done. (...)

Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

So, going by the letter of the Scrum Guide, I would say:

No:

a) Must be completed before the sprint 1 - no such thing

e) Must be done only between the sprints - no such thing

f) Must be done along with sprint backlog refinement - no such thing, anyway, the how and when is up to the team

h) Must be attended by PO and dev team - the how and when is up to the team, and PO can do it alone as well

Yes:

b) Can be done during the sprint planning - the how and when is up to the team

c) Can be done during the sprint review - the how and when is up to the team

d) Must be done only during the sprint - yes, well, everything is done during a sprint, so of course

g) Can be done during sprint retrospective - the how and when is up to the team

Bottom line... No one is saying that the ceremonies are necessarily the perfect occasion for refinement, but it helps achieving the purpose (e.g. if it helps creating a better Sprint Plan during the Sprint Review), then why not?

Then...

What exactly is meant by adjustment? The product backlog has items, and they have some attributes, if the attributes are changed, are we not refining them in some way for better understanding of the intended audience?

As I see it, refining PBL items is just one of the many types of adjusting a PBL (or its items). Adding, removing or reordering items are other ways.

for option g) --- the scrum guide mentions --- "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting."   --- the one item identified is put where? in Product backlog only right? Since the current sprint is ending and the next one can be created from the product backlog in the next sprint planning planning meeting.If the item is not put in product backlog where do we maintain it?

Speaking very technically: the SG suggests adding the process improvement item directly to the Sprint Backlog of the next sprint. As the story is identified during the retro, that means that it must be sufficiently refined to add it, either during the Retrospective the Sprint Planning itself, as there is no time in between. As the Sprint Backlog is a subset of the Product Backlog, that means that it is also by definition a Product Backlog item. But I agree that it's a bit of a weird addition to the SG and it's often hard to fit it into the streamline of "normal" items that often go through a longer period of more preparation to get "Ready".

But remember: Scrum is a framework for developing, delivering, and sustaining complex products. Scrum or the Scrum Guide are not Ikea construction manuals for every work process. They're there to help you empirically grow processes, ideal to your environment and your stakeholders. If something seems to not fit in the Scrum Guide, the most important thing is to hold it against the light of the empiricism pillars and the scrum values, and the goals and purposes of the artifacts/events/roles. 

Hope this helps.


01:55 pm November 5, 2019

@Tony Divel - thanks for your comment. Agree with "Refinement doesn't always have to be such a formal event and could happen ad hoc at any time." Hence it can or may happen during any other events during the sprint including Sprint Review, Sprint Retrospective? It's fine if it does not happen during those events, but can happen? Please comment.

For "I believe the Scrum Guide addresses this and the retro action item is to be put in the Sprint Backlog for the upcoming Sprint as it is an item for the Development Team to improve upon. " --- so essentially Sprint backlog for next sprint starts taking shape during the last sprint's sprint retrospective itself? Is that allowed. Also as @Bouke mentioned, product backlog is super set for sprint backlog hence, it must have entry for the activity identified that will be taken care of in the nest sprint? Please comment. 

thanks

V.

 


02:04 pm November 5, 2019

Hence it can or may happen during any other events during the sprint including Sprint Review, Sprint Retrospective? It's fine if it does not happen during those events, but can happen

I agree with that. If the team is refining during a retro chances are they're moving away from the spirit of that event. As a Scrum Master I may make a decision to help move the team back to focus and table it for a more formal refinement. During the Review it may make sense to get some more details out of the stakeholders while in the room but maybe not go into the technical implementation discussions. To me it's a balancing act of sticking to the spirit of the events while in them but not stifling creativity and good conversation should it go there. 

Sprint backlog for next sprint starts taking shape during the last sprint's sprint retrospective itself?

If it helps to envision the retro item hitting the Product Backlog first and being pulled in then I think that's okay, however, one of the goals of the retrospective is to come out with an actionable improvement to be pursued by the team. I wold agree the Sprint Backlog could start taking shape during the Sprint Review and Retrospective of the prior Sprint. The Sprint Review can result in a reordered Product Backlog which would inform the next Sprint. The Retro can also result in actionable improvement items that can be taken on by the team in the following Sprint as well. 


02:05 pm November 5, 2019

Thanks @Bouke Bergsma for your comment. The whole question is merely a play of words, to confuse the test takers what the correct answer is. Their fundamentals must be strong to rule out the incorrect options.

And thanks that you mentioned:

"But remember: Scrum is a framework for developing, delivering, and sustaining complex products. Scrum or the Scrum Guide are not Ikea construction manuals for every work process. They're there to help you empirically grow processes, ideal to your environment and your stakeholders. If something seems to not fit in the Scrum Guide, the most important thing is to hold it against the light of the empiricism pillars and the scrum values, and the goals and purposes of the artifacts/events/roles. "

Lastly to have options b, c, d, g, h correct, i have re-framed the question a bit    :-D

1.       Product backlog refinement and adjustment

a)       Must be completed before the sprint 1

b)      May be done during the sprint planning

c)       Can be done during the sprint review

d)      Must be done during the sprint

e)      Must be done only between the sprints

f)        Must be done along with sprint backlog refinement

g)       Can be done during sprint retrospective

h)      May be attended by PO and dev team

I am still seeking advice from the grand masters of scrum out here.

thanks

V.

 


03:39 pm November 5, 2019

Wait what, you wrote the question yourself?

Ok, let's go again.

1.       Product backlog refinement and adjustment -- I don't see how including other PBL adjustments changes anything. PBL changes are only done by the PO, or by the development team at the PO's discretion.

a/c/e/f/g seem unchanged. For the other three, I don't see how your rewordings change anything:

b)      May be done during the sprint planning -- Can/may... What would that change?

d)      Must be done during the sprint -- Still the same "duh, everything is in a sprint, so of course!" :)

h)      May be attended by PO and dev team -- Still the same answer; it's up to the team.

On a whole, I appreciate large attention to detail and you bring up interesting questions. I like this :) Typically we say that a Sprint Backlog is created during (and not before) the Sprint Planning. The Scrum Guide seems "weird" when it says both:

- "By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint." 

and

- "it (the SBL) includes at least one high priority process improvement identified in the previous Retrospective meeting."

Contemplating the theory, I guess that "should have" actually implies "must have" if the second part always work. But maybe my feeble non-native grasp of the English language is insufficient to conjoin the necessary contexts and connotations of both auxiliary verbs, so I'll just assume that's what it means. (Ridiculous vocabulary intended ;) )

Secondly, it suggests you can ONLY pick process improvements during the previous retro, not from earlier retros. Which would IMO be fixed by describing it like this: you add the process improvement item(s) to the PBL during the retro, and then pick one from the PBL into the SBL during the subsequent planning. You could make the actual decision on which of them you put in the next SBL in the next Planning, and then it would also not violate the "don't start creating SBL's in the previous sprint" idea.

That's just theoretical nitpicking though. Remember: people over processes. Just like no one cares whether the coffee or lunch break between the retro and the planning is considered to be part of the last sprint or the new sprint, there seems to be no reason to worry too much about how exactly to define this. The point is obvious: it's an extremely good idea to stimulate yourself to actually keep identifying process improvements, because especially in very mature teams this often disappears. And it's also an extremely good idea to try and pick them up quickly so you keep your feedback loops nice and short and you train yourself in improving your own processes.


09:50 am November 6, 2019

Thanks for your comment again @Bouke Bergsma. And thanks a lot for appreciating the deliberately poorly worded question for the test takers. Your comment "Secondly..." exactly resonates with what I was thinking. And I would still encourage the SMEs out here to talk more on that. 

----

Must - means it is mandatory for something to be done

Can - means they have ability or permission to do something

May - means they have a possibility to do something, depending on their own likeness, perception or merely need

----

Hence, IMHO - when I say "May be attended by PO and dev team" or even "Can be attended by PO and dev team", the statement becomes true - since as you said - it depends on team to decide how they wanna take this forward.

As I said - the question is all about play of words. And the test takers must be very clear on their fundamentals.

thanks again,

V.


03:33 pm November 6, 2019

It is purely my opinion, but I would maintain that while Refinement may occur at any time during the sprint, the act of refinement may detract from the purpose and value of the Sprint Retrospective.

While you certainly want to use the Sprint Retrospective to identify an improvement item (Kaizen) for the upcoming sprint, the Scrum Guide specifies that such an improvement item should be added to the Sprint Backlog.   Since the Sprint Backlog is an artifact created in Sprint Planning, I would argue that the actual refinement of that improvement initiative (i.e. - adding detail) should take place during Sprint Planning.

To me, this is easily managed by the Scrum Team, since the Sprint Retrospective marks the end of the sprint, and Sprint Planning marks the beginning of the next sprint.   They should be back-to-back events for a Scrum Team.


09:15 am November 8, 2019

Thanks for your comment @Timothy Baffa. Agreed with your point too. But your argument assumes one thing - we have both sprint retrospective & sprint planning happen back to back. If they do happen back to back, but there is a gap of one night (this will happen mostly in case of one month sprints, where the suggested time for sprint planning is 8 hours - kind of whole day), the identified item from retrospective will have to be documented somewhere, and since sprint planning has to happen on the next day, where we will start with sprint backlog work for next sprint, the item will go somewhere right? That could be anywhere, a paper stored in drawer, a notepad file on my system, but for most effective tracking, it must be in saved in....and yes it will be managed most easily as you said. 

Thanks again!!! 

V.


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.