DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • What Is JHipster?
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Which Is Better for IoT: Azure RTOS or FreeRTOS?
  • Is Podman a Drop-in Replacement for Docker?

Trending

  • What Is JHipster?
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Which Is Better for IoT: Azure RTOS or FreeRTOS?
  • Is Podman a Drop-in Replacement for Docker?
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Moving Items Backwards on a Kanban Board

Moving Items Backwards on a Kanban Board

Mitch Pronschinske user avatar by
Mitch Pronschinske
·
Feb. 10, 10 · Interview
Like (0)
Save
Tweet
Share
18.06K Views

Join the DZone community and get the full member experience.

Join For Free
A question that comes up a lot and is discussed at great length during Kanban conferences is whether or not you should move an item backwards on a Kanban board.  Sometimes an item will have made it to the implementation station, but for some reason needs to be redesigned.  If the team wants to move it back to the design station, or even the analysis station, what should they do?  The kanbandev Yahoo group had several strategies and suggestions for this kind of situation.  Although there's no single right answer, there are several factors teams should take into account.

Moving Cards Backwards
Many Kanban practitioners find it easier not to allow items to go backwards at all.  Even if you do decide to move an item backwards, it is still recommended by some that you don't violate the WIP limits.  It could cause a work-overload if you have too many cards in one column.  However, if you're still hell-bent on moving that card back, try moving back the lowest-priority item from the column that's receiving the backward-moving item.  Repeat that strategy if there's full-capacity on the column getting the low-priority card as well.  The chain reaction will seem like a combination shot in billiard balls with each successive card getting knocked back by the previous one.  Obviously, this can be disruptive if you're not careful.  Some users of Kanban won't say that WIP limits must be followed at all costs in any situation.  If finishing a feature in its current form doesn't make sense, the team should push it back.  Some teams don't mind pushing an item that needs "rework" to an upstream station.  Another strategy is to push the item two steps upstream, marked as "ready to pull" regardless of WIP limits.  

Strategies That Don't Involve Backward Movement
There are a few tactics that don't involve moving back the card that needs to go through a specific station again.  You can turn one station into a rework station and just move the bug cards to that station while the item remains in its current station (however, this process doesn't necessarily involve bugs everytime).  The "rework" card can even be colored differently as a visual indicator.  Work can continue on the item remaining 'in situ', but the bugs should be treated as an expedited request so the system doesn't stall.  This system can be faster than moving an item back and it doesn't break the WIP limit, but it can also lead to swarming behavior.  There are Kanban applications that can mark a card as "blocked" when entering a rework.  The user can enter a reason and email notifications can be sent out.  In extreme cases, you should tear up the card and reconsider the value and approach.  After that, the team can try putting it through again.  In certain contexts, it's better to either 'tackle them' or 'destroy them.'



Why Did You Need to Move it Back in the First Place?
Teams generally find it necessary to do a root cause analysis when they feel that they have to disrupt the flow of the Kanban board by sending items backwards.  If sending a ticket backwards has negative consequences, the team will usually change their policy to leave cards in place.  If "stop the line" side effects from fixing a problem 'in situ' become problematic as well, then the team will start to think about prevention and pursue root cause analysis.  Teams must ask themselves: "Why did a card move downstream prematurely?" and "What can be done to keep it from happening again?"  Some teams will allow their cards to move backwards, but they will flip them over to add a timestamp and record the reasons behind the move.  The team can come back to the record later and reflect on these issues in their retrospectives, which should be done on a regularly occuring cadence. 


A Question of Policy
There are many variables to consider when a team decides if it should move an item back or not.  It depends on the organizational maturity, the type of work you're doing, the organizational culture, and the risk profile of the project.  The decision to either leave an item in place or to send it backwards is ultimately a judgement call and a policy choice.  Whether or not you allow the WIP limit to be exceeded while doing so, is also a policy choice.  You don't have to be right every time.  That's why teams go back to the mistakes they made and modify their policy.  Once the team has a policy that is explicit, transparent, and works well in most situations, they need to stick to it.  Policy should be your guide when dealing with work that is blocked or defective.

For more information on Kanban and Limited Work-in-Progress, visit the Limited WIP Society website.
Kanban (development) Kanban board teams Cards (iOS)

Opinions expressed by DZone contributors are their own.

Trending

  • What Is JHipster?
  • Replacing Apache Hive, Elasticsearch, and PostgreSQL With Apache Doris
  • Which Is Better for IoT: Azure RTOS or FreeRTOS?
  • Is Podman a Drop-in Replacement for Docker?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: