1

We have an optional column for Review, only 20% of tickets need reviews and most don't. Here are our columns:

  1. Todo/Backlog
  2. Development
  3. Reviewing
  4. Testing
  5. Done

How do I implement optional columns in Kanban? My key concern is: An optional column breaks the "pull" concept of Kanban. Once a ticket has completed development, we need to decide if the ticket goes to Review or straight to testing. The Review or Testing columns can't pull from this column

3
  • 1
    What is the purpose of the Reviewing column? Why do only 20% of work items need review? Why don't the other 80% need review?
    – Thomas Owens
    Feb 8 at 19:54
  • @ThomasOwens reviews are requested by implementors for anything from technical clarity, product input, design etc. Most tickets are well hashed and don't need reviews.
    – Nash
    Feb 8 at 21:17
  • Perhaps the issue is why 1/5 of your work items need a review because of lack of clarity. It seems like that could introduce rework and rework is waste.
    – Thomas Owens
    Feb 8 at 22:05
2

If some of your items don't need review (although I think that's a bit unusual for a development flow), you can split your Development column in three sub-sections, something like this:

  1. Todo/Backlog
  2. Development ( Doing | Ready for review | Ready for testing)
  3. Reviewing
  4. Testing
  5. Done

Once a ticket has completed development, you decide if the ticket goes to Review or straight to testing and signal this by placing it in the corresponding sub-column of Development. The Review or Testing can then pull from there.

3
  • Thanks! This will also mean that the Review column will have a Reviewing | Ready for testing columns as well? Implying that testing can source tickets from either columns?
    – Nash
    Feb 8 at 21:18
  • Also, why do you think it unusual for not items to require a review? Is a 100% review more common?
    – Nash
    Feb 8 at 21:19
  • 1
    If it makes sense to split that column too, you can do it also; there are no rules in Kanban as to how to structure your board. As for the second question, I find it unusual because people usually agree on some workflow to handle development, no matter what kind of development. I was thinking code reviews for example, or some acceptance criteria that all work must match, with no exception. I'm not saying it's wrong, just unusual for me. If it's a good work flow for you, then go with it.
    – Bogdan
    Feb 8 at 21:35
1

Based on the comment that the Review column is for work that the implementer has identified as needing additional technical clarity or product or design review, I would suggest that the best course of action would be to remove the Reviewing column and address the underlying root cause(s).

Since Reviewing comes after Development, if the work was unclear and that review results in a changed understanding, the end result would be rework. Overprocessing (doing unnecessary work) and rework (either needing to do more work after inspection or inspection resulting in errors that result in the work being discarded) are two of the 7 wastes from Lean. The overreliance on inspection (which could also include testing) is also one of W. Edwards Deming's key principles for quality.

Depending on your process, the work should be sufficiently defined when it enters the Todo/Backlog column or you can consider moving the Reviewing column to before Development and have all work items move through that state, even if their time in it is very short. If there are ambiguities, the people performing development and testing can make sure that they agree on what the work means so it has a higher chance of moving through Development and Testing processes without issue.

1
  • Thanks, @thomas, this is great advice!
    – Nash
    Feb 8 at 23:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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