How our team uses Kanban to develop software

We are excited to share the way we use our Kanban board to develop software. As big fans of the expression “eating your own dog food”, we use our own software to develop that same software. This approach is very helpful to ensure the highest quality and keep pushing ourselves to always be in the shoes of our customers.

In this article, we will share screenshots of our board in the main stages of the process.

The full board

When building a Kanban board you must visualize your entire process. For our team, we decided to represent the process from ideation to implementation.

As you can see in the screenshot above, the board has default columns “Backlog”, on the left, and “Archive”, on the right. As a team, we decided to create a column called “Read Me” prior to our process columns. We will explain in the next section why we included this “Read Me” column and how we use it to help our team members get up to speed fast.

After many variations, we settled on the following main 7 columns to represent our overall process of developing a software application:

1. Groom
2. Prioritize
3. Plan
4. Develop
5. Test & Release
6. Verify
7. Done

We will explain each of the 7 columns in the sections below. At this time, simply consider the high-level view of the entire board. As you will discover shortly, each of these main columns has its own sub-columns. Keep in mind that we have been using this board for over a year, so it has evolved and been fine-tuned for a mature Agile team.

The “Read Me” column

As Agile coaches working on developing the Kanban Zone application, we love transparency and radiating information. Although the “Read Me” column is not a step in our process and is not be on a typical Kanban board, we utilize this first column as a way to store information to help the team succeed. Because focus and efficiency are critical, we store all key information in this “Read Me” column, and these cards never move.

As you can see in the screenshot above, we have created three vertical sub-columns to store the following information:

• “Research” – Having our research within cards helps us save time by not duplicating decisions based on previous research.
• “Team” – We currently have 7 team members, so we created 7 cards. Each card contains a team member’s contact information, as well as their skills and background.
• “Documentation” – We only document what is valuable to our team in specific cards. By having only a few cards to store our key documentation, it promotes the behavior of keeping these cards up to date, which is one of the most fundamental aspects of documentation… either you maintain documentation or you trash it. These cards also save a great deal of time when on-boarding a new team member by simply showing them these cards.

In the end, our team has never had the need to use an intranet, portal, or wiki because everything needed is right there on the board in the “Read Me” column and within each card that represents to work to accomplish.

Step 1 – Groom

In Scrum, the team often uses a Kanban board to visualize the tasks of their sprint (cycle time) and manage their backlog separately (lead time). Because we work on a single product and team, we have chosen to visualize the entire end to end process on a single board. This has the huge advantage of seeing the whole picture and also identifying our bottlenecks across the entire process.

In the screenshot above, we have broken down the activity of grooming our work into three steps (Product, UX, and Engineering). Our Product Owner is responsible for reviewing every card from the backlog column before they move forward on the board.

• If the card represents a story (or enhancement), then it must have acceptance criteria on the card.

• If the card represents a defect, then it must have steps to reproduce on the card.

The purpose of the “Product” column is to ensure that the Product Owner only moves forward cards that align with our vision, and have complete and current information for the team to efficiently deliver the card. The “User eXperience (UX)” column is for our UX expert to review cards that require UX by attaching visuals to the card prior to letting the card move forward. This column often generates great conversation about the card and helps refine the acceptance criteria. The “Engineering” column is for our Architect to consider impacts, dependencies as well as architectural constraints. The card can be broken into smaller cards and additional engineering considerations are added on the card. Often the acceptance criteria are improved or augmented in this column.

Please note that although we have three key roles (Product Owner, UX Designer, Architect) working in these first grooming columns, the other members of the team brought in to provide input on these cards. What should be very apparent at the end of the “Groom” step, is that each card is very well understood, and the way to inspect that is by seeing the acceptance criteria written in the BDD Gherkin format of Given-When-Then.

Last note on this first step… Each of the three horizontal sub-columns (Product, UX, and Engineering) are also broken down vertically with the ability to organize the cards into three different states (Grooming, Next, Hold).

Only the “Grooming” state (column) has a WIP limit (Work In Progress) of 2 cards to ensure laser focus on only a few cards. As you can see the “Product – Grooming” column is red because it’s over the WIP limit (8 cards instead of only 2). This is my column and as the Product Owner, I am ashamed of this situation as I write this blog. I will make sure to reduce the number of cards back down to 2 cards and move the 6 other cards into the “Next” or “Hold” columns. I also see that I have way too many cards (53) in the “Product” column. Although 25 are in the “Hold” column, it’s obvious that I try to flow too many cards. Luckily, since only the good cards move forward, this problem is mine to resolve and it doesn’t impact the rest of the board or team.

It’s very helpful to use the first column of a Kanban board as a valve to regulate the flow of the work. Each column must also respect that notion, but the first column has to make sure to not overburden the board/team from the beginning of the process. This is also why we have “Hold” columns under each of the three steps under “Groom”. We could have also called this first step “Think” because thinking before doing is smart to prevent wasting the time of the team on badly written cards or really crazy ideas.

Step 2 – Prioritize

The selection of cards from the “Backlog” to the first process column on the board called “Groom” does consider prioritization but from a high level. Once the cards are groomed and ready to move forward, it is critical to compare these new cards with the other cards already in play on the board. Only the highest overall priority card can move forward. This is again a step to prevent wasting the time of our team, but also making sure to think about what is best for our customers.

In the screenshot above, we have a receiving column called “Ready for Prioritization”, where cards can move as soon as they are groomed. This is how we know that the cards have truly cleared grooming.

We have tried many prioritization techniques over the years, but in the end, we simply prefer the MoSCoW technique. By having these four MoSCoW columns next to each other on the board, it’s very easy to compare the cards and assign the right priority level. Please note that because cards on a Kanban board should flow left to right, we listed the four MoSCoW labels in the reverse order (Won’t, Could, Should, Must). Although this might look confusing at first, it helps to have the highest priority cards (Must) as the last column on the right, before exiting this “Prioritize” step.

Step 3 – Plan

“Plan” is the first step where engineers should start pulling work. To avoid falling into the trap of debating the best Agile methodology, we simply use what works best for your team. You can read more about this in our Scrumban article. We are at heart a Kanban team, but we do use great elements from Scrum and eXtreme Programming (XP). For example, in Kanban, we use a continuous flow of work, but it’s nice to get together as a team once a week to talk about the upcoming work. Although this is not a full sprint/iteration planning event, it’s a short but effective way to clarify any last questions before starting the work. We don’t really do 1-week sprint/iteration because the work never stops, or gets assigned to a specific sprint/iteration, but we do like to track our throughput on a weekly basis.

If you want to learn more about the benefits of weekly planning then read our post Plan once a week, deliver every day! So every Monday morning, we (as a team) start our week by getting together for 30-60 minutes to look at our board and discuss what we should plan for this week.

As you can see in the screenshot above, the “Plan” step has been broken into a few sub-columns. Keep in mind that our team uses a continuous flow, so we must always have enough cards for anyone on the team to pull a new card. Here is how we currently have the “Plan” step setup:

• “Pick Up Anytime” – These are cards that we need, but we are willing to let the team pick and choose (read the explicit agreement for the column in the screenshot above).
• “Weekly Planning” – This is the work that we have planed as a team for “This Week” and “Next Week”. The “This Week” column always respects our team’s capacity which we believe is around 8 cards per week, based on our historical weekly throughout. The “Next Week” column should also be at 8 cards, but since this is future work in case the team runs out of work this week, we sometimes go over the WIP limit as shown above (12 cards instead of 8).
• “Regression Failures” – This column is by design the last sub-column to the right under “Plan”, so that engineers always tackle these cards before pulling from the “This Week” column. This column should have 0 cards, but when it does have cards in it, then it’s a clear signal that something urgent needs attention.

This format of “This Week” and “Next Week” has been an experiment for us for the last few months and it has proven to work well for our team. This is one of many ways to queue up your work for the core members of your team to start pulling their work into the very critical/expensive next steps of the process.

Step 4 – Develop

This part of the process starts looking very standard for a software development team. Under the “Develop” step we simply want a smooth flow between the engineers as each card might get touched by multiple engineers to ensure collective code ownership and higher quality.

In the screenshot above, we split “Develop” into two steps “Code” and “Review & Merge”. To ensure that the “Code” meets the original intent, we added a “Check” column to function as a shoulder check between engineers and the original requester.

The “UI Check” column is currently over WIP limit because many of the cards are new screens that require some finessing from our UX expert. The “Functional Check” is a similar column, but between engineers and the Product Owner. This “Check” column is currently optional to prevent this step to slow down all of the cards. The engineers must use their judgment to skip or use this column. Time will tell if this is an improvement to our process, but so far it has helped catch issues earlier in the process, so we see the value to continue using it.

The last subs-column is “Review & Merge” to ensure that all cards go through a “Code Review” before being “Ready For Merge”. Although we use a tool behind the scenes to collaborate on the code reviews, seeing the cards flow on the board to clearly show where they are in the process has been very helpful.

The outcome of the “Develop” step must be working software that is now ready to integrate and be tested.

Step 5, 6 and 7 – Test, Verify and Done

The last three steps all about making sure that the code is ready to be in the hands of our customers.  Just like the multiple “Hold” columns within the “Groom” step on this board, these last three steps have the multiple “Failed” columns. For each environment the code is deployed, tests are executed, and based on the result, the card either moves forward or moves down within the column and into a “Failed” column.

As shown in the screenshot above, our process includes two test environments prior to changes making it to the live environment. Under the “Test & Release” step, the cards must first pass the “Test Automation” sub-column where all of the tests are automated and then pass the “User Acceptance Testing” sub-column where the test manual and exploratory in nature. In order to successfully pass the “Test Automation” sub-column, the use of the latest test automation tools and technologies is of vital importance, as the careful selection of the right tool will perfectly align with the specific requirements of your project and testing procedures. If the card passes both, then they move to the “Ready to Deploy” final column under “Test & Release”. If a card fails any of these test columns/environments, then the card stays in the column/environment where it failed under the “Failed” sub-column. Once the card’s reported issues resolved, as tasked completed on the card, then the card flows again to the next column.

The “Verify” step has two vertical sub-columns “Deployed to LIVE” and “Live Failed :(“

The first sub-column confirms that the card has been deployed to our live environment so that the validation of the change can start in live. If anything goes wrong, then the card moves down to “Live Failed :(” and that is not good because we now have an escaped defect to fix. The later you catch your defect, the more costly it is to resolve it because you have to go back to multiple environments and people again.

The “Done” column is wonderful! Once the card makes it to “Done”, we can celebrate our success and no longer think about that card. On a regular basis, we move our “Done” cards into the “Archive”, so that we can clear that column to receive many new exciting cards.

Last words…

We hope that you enjoyed getting a full walk-through of our team’s board and process. We don’t believe that this is the only way to flow the work for developing a single web application, but we do think that it’s pretty good. If you want to use this board “as is” or as a starting point for your team, then as a business plan member, you can get access to this board template and many other kanban board templates immediately within Kanban Zone.