Scrum with Kanban Guide

Hi Ankush,

That's actuall a sentence we're in the process of revising. Here's the current proposal:

Note that the scope of the definition of "Workflow" may span beyond the Sprint and the Sprint Backlog. For instance, a Scrum Team's definition of "Workflow" may include encompass flow preceding, succeeding, inside, or outside of the Sprint. Similarly, the work items moving through the workflow may or may not correspond to Product Backlog Items or other parts of the Sprint Backlog or Scrum.

does that help? 

I am going through the Kanban guide with Scrum. Not able to understand the following as why it should be 

=========

Note that the states in the definition of "Workflow" may not coincide with the states as defined by a Sprint Backlog

==================

Do you expect that they should always coincide with Sprint Backlog states? If so, why do you consider this to be necessary?

@Yuval, I like the revision. 

@Ankush, Here is my interpretation. Remember that the premise of Kanban is to model your existing workflow for delivery.  In that workflow there will usually be "states" that are outside of the development organization.  For example, I have found in multiple companies I have worked that parts of the delivery cycle are to execute user studies, train support, notify users of upcoming downtime, ensure a backup is done prior to the deployment just to name a few.  Those type of "states" would not part of the process for the development team to provide a potentially releasable increment but are definitely needed for delivery. Since Kanban is focused on the entire workflow from idea to use, I would expect to see "states" before and after the actual steps to build. Scrum focuses on the work to create a potentially releasable increment which would be the "center" of a Kanban board.

Does that help at all?

Refinement is a Scrum activity that might be visualized in a Kanban workflow.

This is perhaps the most obvious workflow to use Kanban for, other than the Sprint backlog.

Thank you all for your thoughts 

According to my experience, Kaban system helps you to manage the various stages of work status. As I have just started my Scrum training at AltegicLearn as a fresher, So I have no more knowledge on it.

 

In Scrum with Kanban guide: Visualization should include the following:

• Defined points at which the Scrum Team considers work to have started and to have finished.

1. Should we limit story points or PBIs? I believe PBIs.

2. Story points estimates, Burn-down charts, Velocity, etc -> Do we need to have them along with basic metrics of flow? 

1. Should we limit story points or PBIs? I believe PBIs.

Which would best support the application of Little's Law, and allow useful empirical measurements to be made?

2. Story points estimates, Burn-down charts, Velocity, etc -> Do we need to have them along with basic metrics of flow? 

Does either the Scrum Guide or Kanban Guide say they are needed, or is the important thing to have projective practices?

We've been practicing SrumBan specially if it's a support work, meaning it's already existing and the only changes are bugs and minor enhancements.

Guys, I found his article created by Applied Frameworks whilst searching for PSK study material:- 

https://appliedframeworks.com/scrum-with-kanban-how-to-improve-your-spr…

In my view, the article and its linked video both seem to be Kanban biased instead of balancing Scrum with Kanban; however, I maybe wrong so am interested in hearing what the Scrum community thinks? 

Perhaps this could be added to the PSK's suggested reading list if the community believe that it useful and will not confuse those wishing to obtain the PSK certification?