Building the Product Backlog During the Sprint Retrospective

One thing I'd like to point out to you based on your 3 current posts.  Scrum is a framework and not a process.  The Scrum Guide is not outlining step by step process.  It is giving general guidelines within which a team and organization can find benefit from the empirical nature of framework.  Process is up to the individual teams to decide as they are self-managing and self-organizing.  What works for one team might not work for another, even if those teams are in the same organization. Now to this question.

A flaw in your logic.  The Sprint Backlog is updated throughout the Sprint. 

Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. 

Using your logic, any additional work identified during the work done in the Sprint would first have to be added to the Product Backlog and then moved into the Sprint.  Items can be added directly into a Sprint Backlog. 

Another flaw.  The Product Owner has this responsibility

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.  

If during the Retrospective the Scrum Team decides that an issue is of high enough concern that they want to work on change during the next Sprint, then that item can be added directly to the Sprint Backlog.  Why wouldn't that be a good idea. 

Furthermore, what would be a Product Backlog Item that maps to an "impactful improvement?"

That is a question that each individual team has to answer.  There is no such rule or formula that can determine this. 

Should the Product Owner be adding to the Product Backlog during the Sprint Retrospective?

Should they -- I haven't the faintest idea. Can they -- yes. 

Anything can be inspected and adapted at any time. If the Product Owner wishes to add process improvements to the Product Backlog during a Sprint Retrospective, for example, they can.

Then again, the team may just decide to tape those improvements to the back of the Scrum Master's chair, and track them that way. Such has been my experience and I merely committed to not hanging my jacket over it.

Wow, we are getting into some very fine-grained, semantic discussions about the Scrum Guide. I love it!

@Daniel says: Using your logic, any additional work identified during the work done in the Sprint would first have to be added to the Product Backlog and then moved into the Sprint.

Not quite.

My understanding is that every Sprint Backlog item must be tied to a Product Backlog item. Is that incorrect?

The Scrum Guide says improvements identified in the Scrum Retrospective can be added to the Scrum Backlog of the next Sprint. If the improvement isn't tied to a specific, existing Backlog Item, would that not require a Backlog Item to be created? And if that is the case, then it would require the Product Backlog to be updated by the Product Owner during the Sprint Retrospective in order for the item to be selectable as a Scrum Backlog item during Scrum Planning.

Maybe I'm Overthinking It?

Perhaps I'm getting too semantic in my response. I guess the Product Owner could just add it in after the Retrospective completes and that would suffice.

Or perhaps any improvement identified during the Retrospective would necessarily be tied to an existing Backlog Item, which means there is no need for the Product Owner to add backlog items.

@Daniel says: Scrum is a framework and not a process.  The Scrum Guide is not outlining step by step process. 

I agree that Scrum is a framework. And I appreciate the fact that we have the Scrum Guide and not the Scrum Instruction Manual. :)

Is Scrum a process? Does it describe processes?

I think it depends on how you define process.

The dictionary definition is "a series of actions or steps taken in order to achieve a particular end."

What is a process?

In terms of that dictionary definition, Scrum is certainly a process. The 'particular end' is the Spring Goal, Product Goal or maybe even the Definition of Done for a backlog item.

And there are certainly steps to be followed. We do Daily Scrums, Sprint Planning happens before development, and the Review and Retrospective happens at the end of the Sprint. Those certainly seems like a set of actions or ordered steps to me.

As always I defer to the Scrum Guide. On Page 8, the Scrum Guide uses the term 'process' to describe 'What can be done this sprint?' "The Scrum Team may refine these items during this process, which increases understanding and confidence."

Really, it all comes down to how you define process. I don't think it's semantically wrong to suggest that Scrum offers some form of a process to software development teams to build upon.

Anything at any time by anyone anywhere!

@Ian says: Anything can be inspected and adapted at any time. 

Well, you wouldn't add items to the current Scrum Backlog during the Sprint Retrospective. I think it's a bit too general to say 'anything at any time.' There are some rules.

Similarly, is the Sprint Retrospective a time where the Product Owner should be allowed to add items to the Product Backlog? My gut feeling is that's not an appropriate time. My other gut tells me disallowing something is wrong. 

Being Persnickity

I hope I don't sound too persnickety.

Thank you for your responses @Daniel and @Ian. You're really helping me think through process (I mean framework), deepen my understanding of Scrum and inevitably, become more Scrumtuous!

The Sprint Retrospective is time boxed to 3 hours, and during that time the Product Owner should be working with the rest of the team to "plan ways to increase quality and effectiveness", according to the Scrum Guide.

So should they be adding items to the Product Backlog at this time? I'd say their efforts are likely better suited to participating in the Sprint Retrospective.

But should there be a rule saying they are not allowed to?

As Ian says, "anything can be inspected and adapted at any time."

I don't think it would be in line with Scrum Values and Scrum Pillars for the Scrum Master to slam down the lid of the Product Owner's laptop if they saw the PO making a pertinent update to the Product Backlog.

Well, you wouldn't add items to the current Scrum Backlog during the Sprint Retrospective.

I'd suggest you might well remove them. There's nothing to stop a team from having included a Retrospective improvement on their Sprint Backlog, for example.

I think it's a bit too general to say 'anything at any time.'

Try thinking about it the other way round. There is a danger in being too specific by claiming otherwise. Scrum is minimally prescriptive: we take care not to rob people of the ability to find the best solution in their own operating context. Hence the Scrum Events provide formal opportunities to inspect and adapt certain things, but they are not meant to be the only opportunities.

There are some rules.

There are fewer than you might suppose. For example, the Sprint Goal may be inspected, and it is the forecast of work which is then adapted. That's a rule concerning the Sprint Backlog. The challenge lies in knowing what these rules are, and how best to apply them in the situation you are in.

I think it depends on how you define process.

The dictionary definition is "a series of actions or steps taken in order to achieve a particular end."

Let's look at the Merriam-Webster definition of a framework

: a basic conceptional structure (as of ideas)

     the framework of the U.S. Constitution These influences threaten the very framework of our society.

b: a skeletal, openwork, or structural frame

      An iron framework surrounds the sculpture.

2: FRAME OF REFERENCE

Frameworks will provide some structure on which you build.  Your choice of using the Scrum Events as process can also be used as showing provided structure.  The Scrum Guide is focused on creating a structure of empirical inspection/adaptation opportunities, not a process for creating things. There are a large number of "steps" that are not described in the Scrum Guide.

My understanding is that every Sprint Backlog item must be tied to a Product Backlog item. Is that incorrect?

I have never seen that stated anywhere.  The Product Backlog contains all items that are needed to be done to the Product.  The Sprint Backlog makes up the plan to create usable increment(s) of value that satisfy the Sprint Goal. It also can contain other items of work not related to the Sprint Goal but those should be secondary objectives for the team.  The Sprint Goal is the primary objective during a Sprint.  In my experience it is not uncommon for something to be created directly in the Sprint Backlog if it is discovered to be needed while executing the Sprint.  

By the way, the statement I made about the Product Backlog above also supports that the Sprint Retrospective improvement doesn't need to be created in the Product Backlog as they are usually focused on improving the team's ability to work together rather than a change needed for the Product. 

I would say that the Agile Manifesto comes much closer to meeting the Merriam-Webster definition of the term 'framework' than the Scrum Guide does.

But I totally agree that Scrum is a framework. I'd never suggested it isn't. I just don't think it's necessary to call someone out publicly for also referring to it as a process.

[Image from Scrum.org]

I think anyone looking at the definition of the word 'process', and then reading the Scrum Guide would agree that it meets the commonly accepted definition of that term too.

"A series of actions or steps taken in order to achieve a particular end."

Scrum clearly defines steps, it clearly defines the end to be achieved, and it states that these steps are immutable, must be followed, and be done in order, or what you're doing isn't Scrum.

It'd be hard to argue that Scrum isn't some sort of a process without deviating away from facts and delving into an emotional argument about what we believe Scrum is.

I also agree that Scrum a framework. I think it meets that definition as well.

What Goes into the Sprint Backlog?

@I said: My understanding is that every Sprint Backlog item must be tied to a Product Backlog item. Is that incorrect?

@Daniel said: I have never seen that stated anywhere.  

I guess it was just my assumption. 

The Scrum Guide says:

"The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."

This seems to imply that a Sprint Backlog item is either the Sprint Goal, the plan itself, or a Product Backlog item decomposed into its essential parts. Thus my assumption that all Sprint Backlog Items (except the plan and the goal) must be linked to the Product Backlog.

Are we saying there is a fourth element that isn't listed here? 

"The most impactful improvements ... may even be added to the Sprint Backlog for the next Sprint."

So are the 'impactful improvements' part of the Sprint Goal, the actionable plan, or are they a Product Backlog item?

Or are they something else? Something that the Scrum Guide missed as being a valid part of the Sprint Backlog?

[Image from Scrum.org]

Great research you've been doing.  I think you may be getting caught up in the details of a lot of things.  Make sure to step back and add the details where they work for your team.  I think the scrum guide was trying to leave flexibility rather than say exactly what (or perhaps how) the sprint backlog should be constructed.  More guidance and detail leads to less flexibility and the guide is trying to balance the two, favoring flexibility.

You noted the sprint backlog items.  If you consider a sprint backlog item a task (rather typical)- it would be odd to have a task that's not related to a selected product backlog item.  That may occur, but it seems odd.  In fact you don't have to use tasks at all, just have a plan (maximize flexibility).  That plan could be tasks, a flow chart (ew), UML diagrams (double ew) a gantt chart (ew squared), or just a set of free form statements.  

The sprint goal is a statement of why the sprint is taking place.  It's best as one statement and i've not seen it as an item but I've seen it "posted" at the top of the board.  See https://www.scrum.org/resources/blog/10-powerful-questions-create-better-sprint-goals.

Sprint goal:  "I want to accept American Express cards credit transactions".  PBIs supporting that goal would be many, and the plan of attack (tasks or SBIs) may include connecting to the AMEX server, sending transactions, getting back responses.