This is a small question to understand Kanban better. Right now, I am managing a Scrum team and decided to learn about Kanban a bit more to understand differences and (if needed) to choose the better development model for my team. The example is based on the real project.

Imagine I have a Software project that is working with Kanban and Continuous Integration. The common task flow in this project is the following:

  1. Backlog - tasks are prioritized and sorted
  2. Implementing - developer is working on the task
  3. Reviewing - task is implemented and the code is under review before merging to the main branch.
  4. Merging - this is an automated step after approved review step. The application build is running on CI server, then auto-tests/unit-tests are running to ensure that nothing is broken. This step can take a while (4-8 hours per change). If everything is okay the change is merged. If it fails, the task should be returned to "Reviewing" step.
  5. Verification - once the change is merged to the main branch another developer should verify that the implementation complies with the "Definition of Done"
  6. Done - all the tasks that were implemented and verified. After that, the tasks are going to be pulled by SQA team for validation, writing test-cases and auto-tests. Due to Kanban limitations (WIP and switching contexts), developers cannot start pulling other tickets while there are tickets that are being merged. It is a waste of 0.5-1 developer day. If there will be no WIP on "Merging" step, then the WIP will be violated on "Verification" step once "Merging" step is done. I cannot throw away the automated step as well, since it is a part of the flow.

So, the questions are:

  • a. How should I account for automated steps in Kanban board?
  • b. What if these steps fail (Kanban discourages moving tickets backward)?
  • c. How would you (re-)organize this flow?

Bonus question:

  • d. How can we enforce through Kanban the rule that different developer should process "Verification" step?

2 Answers 2


I don't think the problem is the automated steps, but the overall process flow.

A few things to consider:

It's not entirely clear on the differences between "Reviewing" and "Verification". It seems like you are developing in branches, so why can't the code review process account for ensuring that the changes satisfy the team's Definition of Done? It seems like in both steps, another developer is looking at the work. By combining these two steps and making sure the work satisfies the Definition of Done before merging, you're eliminating a handoff. Instead of coder -> reviewer -> CI tool -> reviewer, you have coder -> reviewer -> CI tool.

Why does the merging process take 4-8 hours? If you're truly practicing continuous integration, the tests should run in minutes. There are a few things to think about. If you have a lot of very focused tests, consider making your tests more sociable and reducing the overall number of tests - Martin Fowler talks about the differences between sociable and solitary unit tests. Reducing external dependencies may also speed up tests. If you're running the whole test suite, consider running more target tests that focus on the changes or on high-risk pieces of the system to get the test feedback faster. At a running time of 4-8 hours, consider running your full test suite on the main branch either after a merge or every night, depending on how frequently you are merging into the main branch, to get feedback to the developers.

Delaying writing test cases until so late in the process seems inefficient. The isolated SQA team is also probably unnecessary, outside of a handful of cases involving critical software or regulatory processes. If you do need an independent SQA team, they don't need to wait until after the merge is complete to start. They can begin writing their test cases and getting ready as soon as the requirement or change is understood - often, this is in parallel with development.

Consider "Ready for X" steps that do not have WIP limits or have more appropriate WIP limits. For example, after "Implementing", you can have a "Ready for Review" column or after "Merging", have a "Ready for Verification". You may find that it's best to have a low WIP limit in Implementing, but a higher or no limit on what is in Ready for Review. Counting time-in-stage, along with work item aging and cycle time will help you identify bottlenecks in the process. If things sit in a "Ready for X" column for a while, you can inspect your workflow for find how to get things through the following stage faster so people can pull work from Ready.

As far as moving things backwards, I don't think that's a concern, especially in a software project. Kanban originally came from a manufacturing process where it was much more difficult, if not impossible, to move things backwards. If an error was made, it may have rendered the part obsolete. Alternatively, the part would have to go into a different process to be made viable for input again. None of this is truly applicable in a software development context, so feel free to move cards backwards one or more steps as necessary. Having "Ready for X" or "Waiting for X" columns can help facilitate this by giving a placeholder for rejected work.



The focus on representing automation as a separate step is a bit of a red herring, although that doesn't mean the automation problems aren't real. What you're dealing with is really an X/Y problem caused by a lack of smooth process flow.

The solution is to review your entire process for waste, friction, and unnecessary steps. You then need to revamp your processes, tooling, queue management, and working agreements to bring your overall process into as close to a state of continuous flow as possible.

Automation Isn't Inherently a Separate Activity or Status

How should I account for automated steps in Kanban board?

You shouldn't have to, because in most cases the automation is irrelevant to the status or activity. For example, a "testing" or "QA" step isn't really dependent on whether the testing is manual or automated. That isn't to say you can't sub-divide or add additional columns, but you should certainly ask yourself and the team whether doing so adds meaningful value.

Furthermore, your manual review and verification steps sound like anti-patterns to me. Continuous integration should be just that: routine and frequent (ideally continuous) integration into a common branch to test for regressions or conflicts. When possible, code reviews should really be automated by linters and style guides, and "verification" should really be automated unit, functional, and regression testing using a TDD/BDD framework that ensures the code increment meets the Definition of Done. Anything else is really just inserting manual steps into something you appear to consider automated, which seems like a process smell to me.

"Test First" Should Be a First-Class Principle

You also mention that after "Done" you have another group or team writing tests post facto. That's another anti-pattern. Currently, the received wisdom within the agile community is that you should be writing the tests first so that:

  1. You are codifying the Definition of Done for a feature, fix, or improvement before you create the actual change.
  2. You have executable tests and documentation, which ensures that your testing is automatable and that your documentation doesn't fall out of step with the product you're developing.
  3. Validation that new or modified code can be successfully integrated with the existing code base or a new deliverable increment can be successfully automated.

Optimize Your Test Pyramid

[A]uto-tests/unit-tests are running to ensure that nothing is broken. This step can take a while (4-8 hours per change).

While a long-running regression suite before deploying to production might be worth doing, continuous integration best practices rely on fast feedback loops. If your CI is that slow, it dramatically reduces the value of the feedback loop, and provides a huge disincentive for doing truly-continuous integration.

Slow tests are generally a process smell that indicate that you are testing too much of the wrong things, or that you aren't really testing at the right level of granularity. There are many different representations of the test pyramid, and numerous views about how to optimize the testing pyramid for any given domain, but they all basically say similar things about the wide base of the pyramid: most of your tests should be isolated unit tests that run fast so that you can optimize validated learning about the specific change(s) under test.

I suspect that your team is doing some or all of the following:

  1. too much integration or UI testing, or some other form of end-to-end testing, rather than isolated unit testing
  2. writing poor tests that are testing the wrong things, or that have unreasonable overhead
  3. testing things that should be assumed to be valid such as core language constructs rather than your application's logic or behavior (e.g. if you're testing that 2 + 2 = 4 you're testing the language or compiler, not your application)
  4. not ensuring that developers are testing code locally before committing things to the current integration branch
  5. writing non-performant tests, like generating complex or heavy-weight objects rather than stubbing or mocking expensive activities unrelated to the current test

From a project management perspective, these are largely engineering concerns that are out of scope except insofar as they impact cost, schedule, and quality. However, a process that isn't serving its intended purpose is a project management concern, and so you should definitely address the failure of your "CI" (the quotes are deliberate) to be timely and effective for your team.

Your Process Steps Need Better Integration

While inspecting individual components to ensure they meet specifications is important, a disjointed process that doesn't actually build a cohesive increment is inherently broken. If you're building a car, you need to ensure that the axles, doors, or engine parts on the assembly line all meet the correct tolerances so that they can be put together. However, the real measure of success isn't whether a specific part is within tolerance; the goal is to ensure that all the parts can come together to deliver a working car.

Software-related work items moving through a Kanban process are really the same thing as the car metaphor. What's important isn't just the individual steps. What truly matters is the integrated unit or cohesive increment of work that comes out at the other end. Somehow, your current process has lost sight of that, and your current queues, gates, states, and statuses aren't working smoothly together to ensure a properly-delivered increment.

You should work with your team and with your organization to inspect-and-adapt the process to provide a more continuous flow. Part of that discussion is developing working agreements about what to do with work items that don't meet specifications or the Definition of Done. Within a single cycle, moving them back a step or returning them to the starting input queue may be appropriate; if defects aren't found until after delivery then the work unit should either be discarded or placed into the appropriate input queue as net-new work with the appropriate metadata such as urgency or priority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.