User Story or Subtasks / Kanban Board

First of all, I would like to state that we have implemented Scrumban.

That's a bold statement. How do you know you've implemented it? Have you gone through the journey which Corey Ladas described, or does "Scrumban" mean something else to you for which different outcomes are expected?

That's a bold statement. How do you know you've implemented it? Have you gone through the journey which Corey Ladas described, or does "Scrumban" mean something else to you for which different outcomes are expected?

Then I would like to update my explanation as follows. Suppose we are running a scrumban that complies with the rules and the framework. What would your answer be to this question? :)

It is important to be able to visualize the workflow on the board, but what that means is up to you. I can think of ways to visualize the workflow at the story level or the subtask level, both of which would give visibility to stakeholders. There's no right or wrong way that universally, or even frequently applies - it's going to be highly context sensitive.

Suppose we are running a scrumban that complies with the rules and the framework. What would your answer be to this question?

If you were indeed "running a Scrumban" that fully complied with the rules of that framework, you wouldn't have Scrumban at all -- you'd have Kanban. You'd have used Scrum until such time as the workflow and policies stood on their own, quite empirically, and in a context that allowed them to do so without Scrum elements.

Hence:

• The challenge may be non-complex and would not require Scrum. It is not a pick-and-choose framework.
• You'd already know the planning policies needed in order to manage predictability and flow.
• You'd have already recognized this as being context dependent, as Thomas mentions.

However Scrumban seems to mean something else to you, in your context, and with different outcomes perhaps being expected. So what is Scrumban to your team, and why are you doing it? I'd suggest that's what you need to resolve first.

It seems wrong to me to run the progression on the board with more than one subtask for a story

Why would that seem wrong? If you have 1 Work Item (or Product Backlog Item), and at a point in the workflow it is divided into tasks, those tasks each flow through the workflow, so you could have 3 tasks all in the same column, being worked on by different people for one Work Item.



It's when they get assembled back into a Work Item that you wait for all items to arrive and then continue as 1 Item.

I didn't know who had coined the term Scrumban until @Iam mentioned it.  So I looked it up.  I found this video of him explaining it from 8 years ago at a Lean conference.

If you listen to his explanation, he describes how Kanban used a "token" for the value on the board.  All of his discussion then centers on the tokens progress across a Kanban board.  He does discuss how the Scrum Board of the time used tasks and then explains how he builds a board to include a workflow for those items.  But even then, it is a single item that represents the value being delivered that he is moving across the board. 

If you are using the rules and framework, you would understand that the movement and delivery of value is the main focus and the columns on the board represent the workflow that is needed in order to provide that value.  I have very rarely seen that individual development tasks would follow the same workflow as a feature delivery would use. 

Corey Ladas is the Scrumban originator.  He was working with David Anderson to a degree in 2008/9 and started his ideas.

In the PSK class, tasks are discouraged because it can mess with the WIP limits.  You can limit the number of tasks, for example WIP for tasks can be 6, but that doesn't really limit the WIP for the PBIs where the value is really flowing from. In other words you could have 6 tasks in flight AND 6 PBIs in flight.  That would not encourage swarming and flow of value, but rather flow of tasks and work.

Now if you use something like Kanbanize (the tool) and limit tasks AND the PBIs associated to them, that may help.  But keep in mind, from the Scrum.org PSK perspective "Kanban is a strategy for optimizing the flow of value . . . "  not the flow of potentially independent pieces of work. 

Go and try the TWIG simulation: https://analytics.actionableagile.com/twig/index.html

Thanks for all the returns. In particular, I will be reviewing the video and article about scrumban. Kind regards.

To add on to @Chuck's closing recommendation, while you are there get copies of the books by Daniel S Vacanti (Actionable Agile Metrics for Predictability and When Will It Be Done).  They can help you better understand how tracking the right information will help the team become more predictable.