What is meant by the "Scope of definition of work flow" in Scrum with Kanban guide?

An example might be Product Backlog refinement, by means of which work is made ready for Sprint Planning. Product Backlog items which are not yet ready are not part of the current Sprint workflow, but may nevertheless be represented as a state or station in the Definition of Workflow. Hence ready work might perhaps be represented by means of a column on a Kanban Board.

If I understood it right:

The line; "may span beyond sprint and the sprint backlog" is about other columns/state in the definition of workflow which are not related to the ongoing sprint. For instance, we can have a column named "Product Backlog", or "Analysis/Refinement" column to represent High-Priority items that are actively being refined, or "Ready" column to represent already refined PBIs available for the next/upcoming sprint.

Did I get it right?

And besides the above, do teams keep a separate column named "Sprint Backlog" to represent PBIs for the current sprint? Does it make sense to have "Product Backlog", "Analysis/Refinement", "Ready" and "Sprint Backlog" states/columns defined in your workflow?

If those states are meaningful to your team and can help people to maintain a continuous flow of value then why not have those columns?  In my experience, it is not uncommon for columns to be added and removed from Kanban boards as the team and process evolve.  For example you may see that certain items are collecting in a column called "code review".  In order to understand why that column is a collection point, the team may choose to break the "code review" activity into more granular columns for a period of time to see if they can identify the reason for the collection. 

Does it make sense to have "Product Backlog", "Analysis/Refinement", "Ready" and "Sprint Backlog" states/columns defined in your workflow?

Would this help the Developers to understand where their commitment point is, and how work is made ready for it?

Thank you Ian Mitchell and Daniel Wilhite.

Coming back to the first part of my original question, can you also please help me understand what is meant by "Scope of definition of work flow". The word scope is confusing me here. Does it mean all the columns/states in the workflow or something else?

What is the workflow needed to get an idea from inception to complete?  That is the "scope of definition of workflow".  How do you get a good idea into the hands of the stakeholder?  Only a small portion of that is writing code. There could be a need for a cost benefit analysis for larger ideas. Could be a need to create marketing materials for some new ideas or to provide user notification of an impending update.  All of those are steps in the workflow of software delivery.  Those steps may not apply to all ideas but will to some.  The choice of whether to include those steps in your workflow is up to your team. There is also the decision of whether to include those steps as part of the work done within the Sprint Boundaries.  Those decisions can be tied to what is included in the Definition of Done that the team agrees to and commits to achieving for any increment delivered within the Sprint boundary. 

I typically encourage that any steps where someone from the team will/could be involved be included in the workflow for visualization and work-in-progress limitations. But they do not have to be considered within the scope of a Sprint. It can often help others understand what kind of work the Scrum Team is doing and what is included when the Scrum Team says "we are working on that in this Sprint". 

Awesome!

Thank you Daniel Wilhite and everyone else. This was very helpful.