When using Kanban with Scrum, what goes on to the Kanban board, PBIs/stories or tasks?

If it's useful to visualize this, then do so. A lot can be gleaned by examining the boundaries of a system.

A good kanban implementation is a closed model of economic production subject to conservation of flow. Sources and sinks generally need to be visualized so workflow policies can be owned and managed, and weaknesses exposed. Once this is forgotten or ignored you are left with a vanity board with no meaningful commitment point and all hell breaks loose.

@Ian Mitchell.

Thank you for your input. 



Can you please help me understand:

I am having trouble understanding what goes on to the Kanban board when using it with scrum, do we add PBIs/stories or the tasks related to the PBIs/stories?

Will really appreciate your reply.

The item that represents the value that is being delivered is what should appear on a Kanban board, or for that matter any kind of visual representation associated to agile. 

Remember that Kanban was developed by Toyota as way to visualize inventory demands across stations on the assembly lines.  The "cards" represented inventory allotments of specific materials. They would traverse the boards to show the "state" of that allotment because the value was from the materials not the activities that used them.  The columns on the board represented the activity.  So it was able to see that allotment "1AB45 of ignition switches" was being "installed" on station XYZ on the assembly line. 

Take that idea to a board that is visualizing software development.  The feature "Add ability for customer to view their past purchases" would be "in refinement" on the board.  

The purpose of a Kanban card is to represent a work item and communicate its status as it moves through the workflow. Implementing Scrum into Kanban is understanding the difference between "Task" and "Work Items". Task are the steps in the process, which have to be performed by people or system. Where a work item is the task instance that is performed as a single workflow step (Stories). The first (leftmost) lane typically represents the backlog; this is where new requests go before they are prioritized by the individual/team/organization. Before you get started, it can be helpful to define exactly what you're trying to accomplish with your initial Kanban board. 

Can you please help me understand:

I am having trouble understanding what goes on to the Kanban board when using it with scrum, do we add PBIs/stories or the tasks related to the PBIs/stories?

A good kanban implementation is a closed model of economic production subject to conservation of flow. Items on a Product Backlog represent value within that economy, which (when healthy) will be of finite capacity. Hence it's the PBIs that you would seek to visualize and subject to flow conservation policies. There ought to be work in progress limits for user stories, for example. These WIP limits should be low enough to encourage focused throughput by producers (Developers), yet high enough to provide sufficient liquidity for their industry to be facilitated.

Product Backlog items are a bit like units of currency in any economy, which are promissory notes for value. The tasks being performed to release that value may also be represented on the board, but since the work is not intrinsically valuable to stakeholders, they would not be subject to the same policy controls.

Thank you for all the valuable feedback.

I am still confused though. During sprint planning we would break down the PBI/story to tasks, which is considered as your sprint plan. How do we show/present this plan on the Kanban Board? 

Let me please elaborate my question a little more.

Lets say you have a PBI and during sprint planning you break it down to 5 tasks. 3 developers from the team each pull a task from the same PBI. In this case there is 1 PBI, but we have 3 developers working on 3 tasks for the same PBI. How do we capture this on the Kanban Board if we only have the PBI displayed/visible on the Kanban Board? According to what I understood from the comments above, we should be displaying the PBI itself, but then how do visualize 3 developers working on 3 different tasks for the same PBI?

Do you need to visualize it if the Developers are all communicating well?  In reality, they are the only ones that really need to know that detail since everyone else is trusting them to do the work that they have said they will get done.  The detail that people outside of the team need to know is where the item that is providing value is in the workflow.  Do they really care that the task to add a parameter to a function is done but the work to use the data returned from that function is still in progress?  And how would you represent that on the board if you are showing the Product Backlog Item and tasks.  Does the PBI stay in the "in progress" state if some of the tasks associated to it are "in review"?  The workflow is for the item of value, not the individual tasks associated to getting work done.

Boards of any kind are not a replacement for people communicating directly.  They are a point in time representation of information that can be utilized to gain understanding of the big picture.  If you start managing work at a task level, that could become more work than needed. It is not uncommon for some tasks to be completed in hours.  Is it worth asking Developers to manage things at that level?

Daniel Wilhite, I am totally with you on that.

The reason why I am curious to learn how to manage PBIs and tasks related to those PBIs is because in one of the most recent contracts where I was managing 3 cells, we were using Kanban without scrum, and the client's director would every day look at the Kanban Board and generate a report to see how developers and testers are being utilized. The director wanted to see each developer assigned a story on the board to ensure that every one is always working on something (he was not even a fan of pair-programming). He was a difficult client to deal with. There are clients who are daily looking at the Kanban Board to get an understanding of how team-members are utilized and who is idle. According to these clients, one story per developer will increase the throughput and if they don't see a developer assigned a story on the board, they would consider him as "idle" or waste, even though that "idle" developer is probably not assigned something because he/she is helping the tester clear out the queued up stories available for testing or helping another developer where the story has aged beyond the SLE.