Artifacts- inspection an adaption

Inspection

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum Events

The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.  Optimally, all events are held at the same time and place to reduce complexity.

Sprint planning addresses the why (sprint goal), what (PBIs from PB for SB) and how (plan for creating the increment). 

PBIs are inspected against the DoD.  Adaptation is performed during PB refinement, which can occur during sprint planning as well as any time during the sprint. 

The SB is not the adaptation of sprint planing, it is created by the developers when they select PBIs from the PB that usually either align with the sprint goal or are team improvements. 

Yes, the daily scrum is where the progress towards the sprint goal is inspected and the sprint backlog is adapted as necessary. 

Sprint review inspects the outcome of the sprint (the increment) to determine future adaptations.  What was accomplished (done PBIs) is reviewed.  PB may also be adjusted to meet new opportunities based on the collaboration bwtween scrum team and stakeholders. 

As the sprint retrospective is the last event of the sprint, the sprint backlog will not be adapted as at this point there is no SB.  Remember, that any PBI that is not done is re-evaluated and then placed back into the PB before the sprint review starts, as the sprint review only concerns done PBIs. 

Yes, the sprint retrospective is where the team inspects itself based on their performance that sprint in order to plan ways to increase quality and effectiveness.  Any improvements PBIs may get added to the next SB (remember, that tis is no longer mandatory with the 2020 SG; however, it is still a recommended approach). 

BTW, as you have already passed the PSM I & II exams as well as the PSPO I exam, I find it hard that you still do not understand the framework by now.... 

Also, what are you referring to when you mention 'pi'?  Do you mean product increment by any chance? 

Thanks. I do not agree I do not understand the framework. Rather my questions are the result of the deeper (maybe too philosophical) thinking about the topic. And I need to very formalize it. Few thoughts

1) during sprint planning, not only PBIs against DoD are inspected (so to simplify'how much we can work') but also product increment is inspected (to simplify "how our tech debt impacts our performance"), right?

2) why sprint backlog cannot be seen something that is multiple times adapted during the sprint planning? For instance, when the team go from "what" to "how " during sprint planing, they quite often decrease the scope of the work they can commit to during sprint. Is it not something that could be seen as sprint backlog adaptation? Or the sprint backlog is not yet created?

3) During retrospective, Scrum team can add improvement to next sprint backlog. Does next sprint backlog already exists as artifact (but is empty) and they add the item during sprint retrospective? Then it is adaptation of sprint backlog, right? (maybe again- too philosophical). 

I do not think that the existing increment is inspected during sprint planning, as the existing increment is the outcome of the last sprint.  All PBIs that are done in the new sprint have to work with the existing sprints increment, as the increment is built upon in an iterative way via sprints, hence the DoD is there to ensure this is possible.  Of course, sprint planning will utilise other factors when selecting PBIs to add to its SB, as the DoD is there to provide the minimum guiderail. 

I would say that when technical debt is identified, it is placed in the PB as a PBI so that it can hopefully be tackled via future sprints. 

Each sprint has its own SB, and the sprints initial SB is created during sprint planning, this includes decomposing the PBIs for the first couple of days of the sprint.  The SB will obviously be continually refined during the sprint as more is learned about each PBI.  The SB's scope can be changed by the developers negotiating with the PO, as long as the SG is not invalidated. 

An improvement PBI first goes into the PB so that it can be ordered and then possibly selected during a future sprints sprint planning event.  Yes, you could possibly have a number of sprint containers created along with empty SBs if you wanted to, which would then allow you to add an improvement PBI to a future SB; however, I would say that until the scrum team have agreed upon a sprints sprint goal, they will not be able to determine if they will have enough capacity to include an improvement PBI into the sprint until they have reviewed the available PBIs that align with that sprints sprint goal. 

Many thanks. Helpful.

1) I think I agree with you improvement goes first to pb, so there is no any sb adaptation in retrospecrive. I remember in 2017 sg it was obligatory to select at least one improvement to next sprint, but as you said, this happens during planning to ensure capacity etc. 

2) I think that it was mentioned expicilty in 2017 sg that latest product increment is input for sprint planning. Without taking into account some working software aspects (including but not limited to tech debt, here you are right this work should be already in pb)  it may be difficult to create plan as a part of sb (some teams go into the code during planning to clarify important unknows). So I still stand behind the statement that pi is inspected during planning - to help createa plan of delivery (part of sb)

3) what about my third aspect? Is sb multiple times adapted in planning? 

4) I do not agree that product increment is an outcome. I think this is only output (result) of sprint.

See:

https://www.scrum.org/resources/timing-scrum-events

My advice is not to expect to arrive at a definitive answer regarding precisely what is inspected and adapted at any given point. Remember that the Scrum Events are formal opportunities to inspect and adapt. The insight gained through debate is more likely to prove valuable than a conclusion.

Many thanks Ian!