Then I joined a real team.

Suddenly, I was introduced to this thing called Kanban – and I realized I’d been treating software like a solo art project, not a process.

If that sounds familiar, you’re in the right place.

This guide will walk you through how Kanban actually works, how developers use it to track and prioritize work, and how it can help you stay sane when juggling bugs, features, and real-world deadlines.

Without further delay, lets get into it.

Here’s what we’ll cover:

• So… What Is Kanban?

• The Classic Kanban Board: Three Simple Columns

• How Developers Use Kanban in Real Life

• Kanban vs Scrum: What’s the Difference?

• So which one should you use Scrum or Kanban?

• What Tools Do Teams Use for Kanban?

• How to Use Kanban to Manage Your Own Coding Projects

• Final Thoughts: Why Kanban Isn’t Just a Board

So… What Is Kanban?

At its core, Kanban is a visual way to manage work. It helps teams (or team members) see:

• What needs to get done

• What’s in progress

• What’s finished

• Where things are getting stuck

The concept comes from lean manufacturing, but in tech, it’s often used in Agile teams that need flexibility without the structure of Scrum sprints.

Think of Kanban like a whiteboard that tells a story. Not just what’s done, but how work flows.

The Classic Kanban Board: Three Simple Columns

So what exactly is a Kanban board? At its core, it’s a visual representation of your workflow – a board that shows all the work your team (or you, solo warrior) are juggling, and where each task stands.

It can be physical, like an actual whiteboard with sticky notes that move from one column to the next. Or digital, using tools like Trello, Jira, GitHub Projects, or Notion. The key is that it’s visual and up-to-date. You can walk into a room or open a tab and instantly understand: What’s being worked on? What’s ready to go? Where are things stuck?

It’s like having your brain on a wall, but organized. And slightly less chaotic.

The beauty of Kanban is how dead simple it is to get started. At minimum, your board has three columns:

Each task – or card – moves from left to right as it gets worked on.

Let’s say your team is building a blog platform. Your Kanban board might have cards like:

• “Create signup form”

• “Fix image upload bug”

• “Deploy staging build”

Now, while Kanban is flexible, it can absolutely be taken too far.

I’ve seen boards with more columns than a Greek temple: “Needs Review,” “Pending Client Feedback,” “QA Rework Round 2,” “Blocked but Still Hopeful,” “In Existential Limbo,” and so on. Every card had six tags, three owners, two checklists, and one migraine.

The lesson? Don’t turn your board into a bureaucratic jungle.

You don’t need to account for every edge case. Start simple: “To Do,” “In Progress,” “Review,” “Done.” These basic stages cover most workflows. If you discover a real need for something more – like a dedicated “QA” column or “Blocked” column – add it intentionally, not because you feel like your board needs to look fancy.

Remember: A Kanban board should be helpful, not overwhelming. If you spend more time managing the board than doing the work on it… it’s doing the opposite of what it’s meant to do.

How Developers Use Kanban in Real Life

Here’s how you might interact with a Kanban board on a dev team:

1. You pick up a card from “To Do” – let’s say, “Add dark mode toggle.”

2. You move it to “In Progress.”

3. When it’s ready for review, you might move it to a temporary “Review” or “Testing” column.

4. Once it’s merged, tested, and deployed, you move it to “Done.”

5. You smile, drink some coffee, and grab the next card.

That’s it. But over time, this process helps the whole team:

• Spot bottlenecks

• Prevent duplicate work

• Reduce context switching

• Keep everyone aligned

What’s a WIP Limit — And Why Should You Care?

WIP = Work In Progress. This is the most important concept to keep us in check.

One of Kanban’s key principles is limiting how many things you’re working on at once. Because guess what? Multitasking kills momentum.

A typical WIP limit might look like:

• No more than 2–3 cards per person in “In Progress” Again this is best practice, but folks do pick up a lot and then they end up being the bottleneck.

• No more than 5 tasks waiting on QA.

Why? Because when everything’s urgent, nothing gets done. WIP limits force you to finish one thing before you start more – and that’s how real velocity happens.

If there are more than 5 tasks in the “To Do” column, the team doesn’t take up new ones. Instead, everyone chips in to see how they can help unclog the bottleneck. A bottleneck is your worst enemy in Kanban, and you want to resolve it so items move smoothly on time and on target.

Here’s a video recapping key concepts.

Kanban vs Scrum: What’s the Difference?

You’ve probably heard Scrum and Kanban mentioned in the same breath – and both are popular Agile frameworks. But they’re not interchangeable.

Scrum is structured, with roles like Product Owner and Scrum Master, and work gets organized into time-boxed sprints. It’s perfect for teams that benefit from rhythm and rituals – like sprint planning, daily standups, and retrospectives.

Kanban, on the other hand, is a little looser. No official roles, no set sprint timelines. Work flows continuously, and change can happen anytime. It’s perfect for teams who need more flexibility and fewer ceremonies.

So how do they compare in practice? Let’s break it down:

Bottom line:

• Scrum is a scheduled loop. Kanban is a living flow.

• One’s a playbook. The other’s a status window.

Here’s a video on the main differences between Scrum and Kanban you can watch if you want more detail.

So which one should you use Scrum or Kanban?

So… which one should you use?

It really depends on your team, your product, and your pain points.

✔️ If you’re working on a brand-new product where requirements shift a lot, and your team thrives with structure and routines – Scrum is likely the better fit. Sprints give you a sense of pacing, and ceremonies help ensure alignment.

✔️ If you’re managing ongoing work like bug triage, tech debt, infrastructure tasks, or anything that’s more “whenever it comes in” than “we need to ship this in two weeks” – Kanban gives you flexibility and visibility without the overhead.

And yes, there’s such a thing as Scrumban – a hybrid approach where teams use visual boards and WIP limits from Kanban, but keep some of Scrum’s structure like standups and retros. It’s like Agile tapas: you get the flavors that work best for your appetite.

Here is a detailed video that’'ll teach you more about how Scrumban works in practice.

Watch the Scrumban video only when you are familiar and comfortable with both Scrum and Kanban – otherwise, you might get confused from the cross-pollination of ideas and frameworks.

I personally have never seen a Scrumban implementation thats scaled well – too many folks trying too many things and none of them work. But thats just based on my experience – it may work for you and your team. I’ll let you be the judge.

What Tools Do Teams Use for Kanban?

You’ve probably seen (or used) one already:

• Trello – Simple and great for solo or small teams

• Jira – Enterprise-level, customizable workflows

• GitHub Projects – Lightweight but powerful for devs

• ClickUp / Asana / Notion – Integrated with docs/tasks

Kanban isn’t tied to any one tool – you can use an app, a browser tab, or a whiteboard and a pack of sticky notes from the office supply closet. What matters is how you use it. But let’s walk through some of the most common tools and what they offer in a Kanban context:

🟩 Trello

Trello is probably the easiest way to start with Kanban. It gives you a simple digital board with columns and cards you can drag and drop. It’s great for devs or small teams who don’t need tons of automation – just a clean place to track work visually.

🟨 Jira

Jira is a heavyweight – and while it’s built for Scrum, it also supports robust Kanban boards. You can define custom workflows, use built-in reports like cumulative flow diagrams, enforce WIP limits, and manage team velocity. Ideal for large teams that need traceability, integrations, and permissions.

🟦 GitHub Projects

If your code lives in GitHub, GitHub Projects is a clean way to stay close to your codebase. It lets you create Kanban-style boards with issues and pull requests as cards, so you’re never toggling between tools just to track what’s in progress.

🟧 ClickUp / Asana / Notion

These are all-in-one productivity platforms. They combine Kanban boards with documentation, team chat, calendars, and reporting. If your team needs more than just “move card left to right,” these tools let you manage projects, meetings, notes, and workflows in one place.

🟪 Whiteboard + Sticky Notes

Don’t underestimate the analog approach. It’s fast. It’s visible. It’s tactile. Physically moving a task from “Doing” to “Done” gives you a sense of progress no digital tool can match. And when something’s blocked? Slap a red sticky on it and call it a day.

Bottom line: The best tool is the one your team will actually use. Fancy doesn’t beat consistent. And the actual tool doesn’t matter as much as the discipline your team has to actually use it.

How to Use Kanban to Manage Your Own Coding Projects

Even if you're not on a team yet, Kanban is great for your own workflow. Here’s how you can use it to help yourself out:

1. Create a basic 3-column board (To Do, In Progress, Done)

2. Write out every task, big or small

3. Set a WIP limit (for example, no more than 2 tasks at once)

4. Update it daily. Make it a ritual.

5. Review your flow weekly – What got stuck? What moved fast?

Example:

You’ll be shocked how much clearer your thinking gets when you can see your work. It’s simple but super powerful to visualize your work it in this way.

Final Thoughts: Why Kanban Isn’t Just a Board

Kanban isn’t just a tool – it’s a mindset.

It helps you focus. It helps your team collaborate. And it gives everyone – even non-technical folks – visibility into what’s going on.

If you’re learning to code and want to feel more confident working with others, learning Kanban is low-effort, high-impact.

So don’t wait until your first job. Start using it now – and show up to that standup with confidence.

I hope this small 101 Guide to Kanban was helpful to you all. My sole purpose to write this was to help beginner developers understand Kanban as a practical workflow system – especially for those transitioning from solo coding to collaborative, real-world development environments. It aims to demystify the methodology in a casual, beginner-friendly tone while still offering actionable guidance.

I hope you enjoyed my beginners guide to Kanban.

Until next time, keep Learning, Unlearning and Relearning, folks….

Kanban was invented in the Japanese automotive industry in the first half of the 20th century. Inspired by how supermarkets stock their shelves based on demand, Toyota's goal was to reduce inventory and to improve the flow throughout their whole production system.

In his book Kanban: Successful Evolutionary Change for Your Technology Business, David Anderson described how to apply the Kanban principles to software development. These principles are:

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities, and titles

What does that mean for agile software development?

In my training courses, I ask the attendees what they already know about agile software development. Common answers are: "Work in Sprints", "There's a product owner", "Manage user stories in a backlog." People are influenced by the arguably most popular agile framework today, Scrum.

Scrum comes with its own predefined roles, events and artifacts. Scrum requires you to follow the rules defined in the Scrum Guide, if you want to call what you're doing Scrum. Kanban is different.

Kanban starts with the process that you follow in your company now. Visualize the steps on a Kanban board. They can include everything you do, from idea to delivery.

Each step becomes the title of a column on the board.

To track your day to day work, it's best to break it down into small items. Maybe user stories that can be implemented in, at most, 2 days. Write each item on a stickie note, and hang it on the board. You can use the vertical order on the board for prioritization.

The cards move from left to right. The people doing the work pull items that have been finished by the previous process step. When they have capacity to do so. So the developers in the example pull the Upload Image card into Dev when they have the capacity to implement it.

Pursuing incremental, evolutionary change

So you have created a Kanban board that shows your process? You are making your work visible, which is a great start!

To get the benefits of Kanban, you need to do some more things. You need to:

• Limit work in process and queues
• Observe and improve flow
• Collaborate effectively

Limit work in process and queues

Limiting work in process means: you set a maximum for the number of items you work on. That's called the Work-in-Process limit, or in short WiP limit. Here's the Kanban board with a WiP limit for some process steps.

The developers can work on 5 items at a time. At most. If their column contains 5 items, they are not allowed to pull items any more. This has two consequences.

First of all: it encourages people to finish their work, instead of starting more work. Started work that isn't finished bears risks. How happy will your customers be when you can't release your software as planned? Because you started to work on all these great ideas, but you didn't go through with them?

The second consequence of limiting work in process: bottlenecks become visible. When a process step starts work that it can't finish, people will feel it immediately. Because the next process step won't be able to pull items.

Apart from limiting the work in process, you should limit queue sizes, too. In the board above, they are shown as the dotted lines between the columns. It works the same way as limiting the work in process.

In summary: Stop starting, start finishing is the motto. From concept to delivery in as little time as possible.

Observe and improve flow

Observing a bottleneck can be painful at first. But at least you know where the major problems are in your process. And Kanban encourages you to improve the flow by removing the bottleneck. A consistent flow enables you to deliver more reliably, and that's good for all stakeholders, including developers.

To observe the flow, you record the time at which a card enters a process step. And the time at which you complete the process step. So you know how much time the card spends in each step, and in each queue between the steps.

Based on the data, you can set up metrics that help you to improve the flow. Common metrics include:

• Cycle time: the time a card takes from the moment a team starts working on it (i.e. Dev) to delivery (i.e. Release). Improving this metric can help you improve your time to market.
• Throughput: the number of cards that move through the system in a given time. Improving this metric can help you improve the performance of your delivery organization.

A common way to get an overview of how many cards are in which process step over time is a cumulative flow chart. Ideally, the number of cards in each step but the last stays roughly the same over time. The number of released cards should mount. When the chart deviates from that, you might have a bottleneck.

Collaborate effectively

The Kanban metrics are a powerful tool to analyze and improve what you're doing. But they are worthless without the people doing the work. Everybody involved in the process steps should be open to the transparency that Kanban creates.

People should work together constructively to remove bottlenecks, instead of blaming individuals. Look at the current state regularly. Are there any bottlenecks? Is there too much or too little work available for a certain process step? Is throughput sufficient? Are there other sources of discontent? What needs to be improved?

Agree on experiments that try out small changes to the system. Realize the changes. Later, look if the experiments worked out as expected. To be able to implement the changes, management support is often crucial.

When to use Kanban

Kanban is very flexible. It can be used in combination with Scrum, which is called Scrumban. It can be used outside of product development. You can even use it to plan a trip or organize what you do in your free time.

I found it especially helpful when working in Scrum Sprints is not possible or is difficult. Example: two companies where one is customer, and the other is supplier, and a hand-off is inevitable. Another example is when you're working on a product that involves both software and hardware, and multiple engineering disciplines are involved.

Kanban can also be used inside your company when development works in an agile fashion, but not all of the rest of the company does. It can be used to facilitate the cooperation between strategic planning and software development.

Don't think that just because you have trouble implementing Scrum, there's no way to become more agile. Kanban starts with what you do now. And if you take it seriously, it will help you improve. One small step at a time.

To learn more about agile software development, visit my online course. To keep up with what I’m doing or drop me a note, follow me on dev.to, LinkedIn or Twitter. Or visit my GitHub project.

Scrum and Kanban are the two most popular project management techniques today in business. As a developer, I think it's important to understand these processes as you will likely be heavily involved in them if you are part of a team. By understanding, we can stay focused on solving problems and not be too frightened of some of the buzzwords.

I'm a developer by trade but my last employed role was in product management. I tried both of these methodologies to improve productivity and efficiency in delivering products and services in the best possible way. They also assist in making organizations quick to adapt to changes in demand for their products/services.

What is Scrum?

Scrum is a project management methodology designed for cross-functional teams of less than 10 members working on complex projects. Its primary goal is to use the team member's various skills to create a solution/product for the customer/end-user.

The word Scrum is derived from the game of rugby where players of both teams interlock and try to gain possession of the ball as a functional unit.

Scrum runs on three major pillars, transparency, inspection and adaptation. This methodology is based on the premise that the customer/end-user could change their mind about what they want or there could be changes which a planned approach cannot deal with.

The project is usually started with what information is available. Afterwards, changes or tweaks can be made whenever necessary while tracking the developmental process.

The project is broken down into distinct actions called sprints that have to be completed within a fixed timeframe or iterations. The average duration for sprints is usually two weeks to a month.

Progress is tracked through daily scrums which are 15 minutes fixed stand up meetings. This encourages close interaction and communication between team members rather than the traditional sequential approach.

What is Kanban?

Kanban is a visual project management framework which was created from lean software development process and used in Agile project management. The word Kanban is a Japanese word meaning Billboard and was derived from the lean manufacturing methods pioneered by the vehicle manufacturer Toyota in Japan.

It visualizes the work process and progress through Kanban Boards. It's used for products/solutions that require continuous delivery and aims to balance demand with available capacity (Pull system) rather than push out products to the market (Push system).

The aim of using Kanban is to remove bottlenecks during the production process so that the project can flow smoothly and still be kept within budget. It's usually used in combination with other agile methodologies like Scrum.

History

The Evolution of Scrum

The Scrum methodology was first mentioned in a 1986 Harvard Business Review article 'The New New Product Development Game' by Hirotaka Takeuchi and Ikujiro Nonaka.

The authors described this process they initially called the holistic or rugby approach as a new developmental process that would increase the speed and flexibility with which commercial products were brought to the market. They saw it as "good at bringing about innovation continuously, incrementally and spirally".

1993 saw the initial use of this methodology by Jeff Sutherland along with John Scumniotales and Jeff Mckenna at Easel Corporation. Two years later Sutherland and Ken Schwaber co-presented a paper describing the Scrum methodology at the Object-Oriented Programming, Systems, Languages and Applications '95 (OOPSLA) conference in Austin, Texas.

Schwaber also wrote the first scrum text in 2001 along with Mike Beedle called Agile Software Development with Scrum. That same year saw the two authors along with Sutherland and 14 other experts on Scrum draft the Agile Manifesto in Utah which specified the principles, features and values of this methodology.

The Scrum Alliance was created in 2002 by Schwaber to provide a governing body for the Scrum methodology as well as formal certification through the CSM (Certified ScrumMaster) program. Schwaber later left the alliance in 2009 to set up Scrum.org which is in charge of the Professional Scrum Accreditation Series.

Since 2010, a document called the Scrum Guide has provided guidelines for the Scrum methodology and has been revised regularly, with the latest version released on November 2017.

Evolution of Kanban

Kanban started life as a manufacturing methodology promoted on the factory floors of Toyota by Taiichi Ohno, who is known as the father of the Toyota Production System.

Ohno was looking for a way to increase productivity and reduce inefficiencies during the car manufacturing process while avoiding making products that couldn't get sold and lost money for the company.

In a quest to get a solution, Ohno would stumble on it during a visit to a Tokyo supermarket in 1943. There, he noticed that the products on sale were only restocked when they were almost sold out according to customer demand instead of through regular supplies from the vendor. This ensured that the supermarket had very little excess inventory and ran efficiently.

Ohno would bring this technique to Toyota thought it would take 10 years for it to be fully operational. A big part of this process would be the communication system which made use of visual cards called Kanban that illustrated to the workers in each stage of the vehicle manufacturing process what needed to be done, and the materials needed, in clear terms.

It also adjusted the number of vehicles manufactured to the demand by the public instead of utilizing the full productive capacity. This process was also known as lean manufacturing or 'Just in Time' production.

This helped standardize the production process, removed inefficiencies, and made Toyota nimble and flexible by avoiding the accumulation of excess products that couldn't be sold. This was a problem American auto manufacturers were also having.

This turned Toyota into a global auto giant. After its adoption in the automotive industry, the Kanban philosophy spread all over the world and into different industries.

Kanban would become popular in service/knowledge industries due to the work of David J. Anderson. He was an admirer of the lean manufacturing process who applied a pull system of development influenced by Ohno's Kanban philosophy while working with a Microsoft XIT Sustaining Engineering group in 2004.

The next few years would see Anderson and some other colleagues shape the features and principles of the Kanban methodology. The Kanban methodology spread through management conferences and talks and more companies began to adopt it.

Anderson collated his experiences with Kanban in a book published in 2010 'Successful Evolutionary Change for your Technology Business' which is regarded as the most comprehensive definition of the Kanban methodology for Knowledge workers.

The Scrum Principles/Values

Scrum boards are “Kanban boards” too, confusing eh?

The Scrum project management methodology became part of the Agile development approaches which spread in the late 1990s and early 2000s. These were an effort to find a solution to the high failure rate in software development.

The Waterfall Development approach used primarily before this point in the software industry was rigid and inflexible – product development had to follow rigidly laid down procedures and documentation.

Scrum allowed software developers the flexibility and freedom to respond to changes in development. It also called for the involvement of the customer in the development process rather than being a bystander.

This methodology later spread to other industries. Scrum has become the most used of the agile project management methodologies – research indicates that it is in use in 66% of all projects incorporating agile development methods.

Scrum is easy to understand and follow as it avoids rigid instructions and procedures. With Scrum, organizations can do whatever is needed to get the project done, adapting to circumstances that might suddenly arise. This flexibility is one reason Eric Naiburg, marketing vice president at scrum.org, calls Scrum the opposite of a to-do list.

The breaking down of projects into sprints makes it suited for complex undertakings while the involvement of the customer in the development process enhances transparency.

The Agile Manifesto

The Agile Manifesto set out to address frustrations among software project developers in 2001 and came out with four principles. Today these principles are the bedrock of the Scrum project management philosophy and have spread beyond the software industry. They state that projects should value:

• Individuals and interactions over processes and tools.
• Working products/solutions over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Scrum Best Practices

• There are some best practices which underpin the Scrum methodology.
• We are ensuring Customer Satisfaction through early and continuous product delivery.
• Testing and incorporating product owner feedback daily.
• Welcoming and responding to changing requirements even late in the development process.
• We are working together with the customer on the development process.
• We are providing the support and environment for motivated individuals to get the work done.
• Emphasis on face to face communication within and to the team.
• We are measuring progress through a working solution/product.
• We are promoting development at a sustainable pace.
• We are enhancing agility by devotion to technical excellence and good design.
• Self-organizing teams being the best way to get the best architecture, requirements and designs.
• Having regular reflections on improving effectiveness through sprint reviews and adjusting actions to suit such.
• We are respecting the balance between the team members' professional and private lives to keep stress to a minimum.

Benefits of Scrum

The scrum methodology is the most widely used agile project management methodology for the following reasons.

Freedom of initiative — Professionals who love the freedom to take initiatives are in love with the scrum process due to its self-organizing ethos. This tends to boost team morale.

High-quality products/services — Products and services that are produced using the scrum process tend to be of a high quality due to the various iterations and improvements they have had to go through as well as customer involvement in the development.

Shorter delivery times — This is a result of the incremental development process which shortens the delivery time by 30%-40%. The involvement of the customer in the development is also a factor here.

Better return on investment — This is as a result of the shorter delivery times, better product/service quality and fewer defects as a result of continual feedback and the early testing.

Flexibility— Teams are able to react quickly to sudden changes in the market and reflect them in the product/service development.

Drawbacks of Scrum

Like everything else, the Scrum process does have its limitations. Here are some of them.

Need for expertise — Scrum requires professionals with expertise and training on the scrum methodology. This requires upfront investment by the organization.

Scope creep — The customer could request too many modifications on the product/project, which could turn out to be unnecessary.

Expensive — The need for high expertise during the scrum process as well as the constant events makes the scrum process expensive to operate

The Scrum Process

Scrum Teams

The process starts with the formation of a Scrum team to work on a pre-defined solution/project. These teams are usually self-organizing and cross-functional. According to Scrum principles, self-organizing teams are the best way to ensure optimal performance on a project as they can influence how the work will be accomplished rather than follow external directions.

Cross-functionality refers to the different competencies among the team members which enable the Scrum team to have all it requires to accomplish the project within and does away with the need for external help.

An ideal Scrum team shouldn't have more than 9 members to enhance the team spirit, closeness and effectiveness. It's also important that the team members are in the same physical location or are at least online constantly if they work remotely.

Scrum Teams deliver solutions in increments, incorporating the views of the product owner at each product's iteration. This ensures the constant availability of a functional product. There are 5 values or principles which every Scrum team should abide by in order to be effective.

• Commitment — Working towards the team goals at every sprint.
• Courage — Being able to do the right thing despite conflicts and challenges.
• Focus — Concentrating on the team goals and the sprint backlog exclusively.
• Openness — Being transparent with one another about the job and its challenges.
• Respect — Respecting each and every team member.

Scrum Roles

There are three distinct roles in any Scrum team: the product owner, the Scrum Master, and the Development team.

Product owner — This person represents the customer in the Scrum team and has the responsibility of ensuring the team delivers the project/solution/product according to the customer' s/end user's specifications. They have to communicate the end user's product requirements as well as the customer's feedback at each product's iteration. They also manage the product backlog which identifies the features of the product to be worked on.

Scrum master — This individual ensures that the team follows the Scrum principles and guidelines. They ensure that whatever is needed for the project is made available and take care of any impediments obstructing it. They also facilitate team events and ensure proper communication.

Development team — This comprises the rest of the Scrum team. They have to work together to provide a product/project using their various competencies. They organize themselves and choose their own path in getting the product delivered.

Scrum Events

Communication is vital in the Scrum framework. This is enshrined in the five events or meetings where information about the development process is exchanged regularly.

Backlog refinement — The product owner regularly reviews the product backlog which refers to the list of product features, the work to be done, and the sequence of delivery. They make sure that the backlog is properly prepared in a way that communicates to team members what needs to be done at each sprint.

Sometimes, the order of work has to be modified due to customer feedback or reviews from the development team. The review of the backlog, which is done in between the conclusion of a sprint and before the start of a new one, prioritizes features based on factors like business value, risk and date the features are needed. This review usually delivers the content for the next sprint.

Sprint planning — This is done at the beginning of a sprint to plan what needs to be worked on by the Scrum team. The smaller parts which a project is broken down into are called sprints. They could last from a week to a month.

The sprint meeting, which usually lasts an average of four hours for a 2-week sprint, has the team choosing the backlog items that can be completed during the sprint, how it will be worked on, and the goal for the sprint. These are all included in a sprint backlog.

Daily scrum/stand up — This is a quick daily stand up meeting that lasts a maximum of 15 minutes. The previous day's work is reviewed and challenges are identified by the team as well as individual members.

An individual is tasked with getting solutions to any challenges identified and any uncompleted work from the previous day is highlighted by the Scrum master on the scrum board.

Detailed discussions aren't allowed during scrum meetings. The strategy to be used for the day's work is also agreed upon.

Sprint review — This meeting which is held at the end of the sprint is used to review the performance of the team. If the work for the day is completed, the product's iteration is demonstrated and then presented to the customer/end-user along with the sprint backlog containing the 'done' items for their feedback.

The product owner can also make adjustments to the product backlog at this point.

The recommended duration for the meeting is usually a maximum of four hours.

Sprint retrospective — This is an opportunity for the Scrum team to reflect on how effective they were and what could be improved upon for better productivity the next time.

Scrum Artifacts

This refers to the commonly used tools in the scrum process. These are three of them used to record the progress of the Scrum team as well as details of the project.

Product backlog — Is a list of work that has to be done on the project by the scrum team. It contains the product requirements, features to be worked on and bugs that have to be fixed. It's overseen by the product owner and serves as a guide to the team. It's usually reviewed before it makes it into the Sprint backlog.

Sprint backlog — This list which is overseen by the development team refers to the list of product features from the product backlog that has to be worked on during the present sprint.

Team members sign up to handle tasks they can handle based on their competencies in the spirit of self-organization and commitment.

Sprint backlogs can be modified during a sprint but the end goal remains constant.

Product increments — This is the end result of the work completed during a sprint. It's usually added to the completed work from previous sprints.

This is usually according to what the Scrum Team defines and agrees as 'Done' status. Most times, this means the product is functional at an optimal level and ready to be delivered to the customer/end-user.

The Kanban Principles and Practices

The Kanban Principles

There are four core principles which form the bedrock of a successful implementation of the Kanban methodology.

Start with the present system — Kanban methodology stresses the need to avoid a culture shock by introducing a new system overnight. Instead, it can be brought into an organization and applied alongside the existing techniques.

This makes Kanban easy to implement and non-disruptive. Changes can then be implemented at a speed that everyone is okay with within a long gestation period while information about the current workflow and its inefficiencies are collected and analyzed.

Make changes incrementally — The Kanban methodology emphasizes gradual and small changes to the status quo. This will enable more buy-in from the organizational members that will be affected by the process, reduce uncertainty and unease, and in turn enable the organization to be turned around for the better as the evidence from previous incremental changes is apparent.

Respect the current workflow processes and roles — The existing work process, functions, and those in charge of them are not done away with immediately when the Kanban methodology is implemented.

The team will decide what roles should be modified, what changes should be introduced, and the right time they should be done. This is to ease the organizational transition among the members and make the incremental changes acceptable among them.

Encourage leadership at every level — Kanban recognizes that leadership qualities can emerge from anybody no matter the level they are in an organization. This is why team members are encouraged to act when there is a need for changes or to kick off initiatives instead of waiting for superior or senior management to order them.

This principle fosters trust and continuous self-improvement (Kaizen) among the team members, helping them to reach their optimal performance levels which will boost organizational productivity in the long run.

Kanban Practices

In order for Kanban implementation to be effective, there are six Kanban practices which teams have to put into action.

Visualize the workflow process — This is the first step when using the Kanban methodology. The process used to deliver the products/services by the organization as well as its flow has to be illustrated on a Kanban board which could be physical or electronic.

Each step in the workflow is represented by a column on the board. The different work items are denoted by Kanban cards of different colours. A collection of related work items can be bunched together using Kanban swim lanes.

The main aim of these is for all parties to understand the functioning of the workflow process from the customer request to the final product/service delivery as well as improve communication and collaboration. With this, different areas of the work process can be tracked and analyzed to identify possible impediments which can be worked on.

Limit the work in progress (WIP) — With Kanban, a manageable number of work items should be worked on at a time with a limit placed on the work in progress that can be handled. Work at hand should be completed before moving on to 'pull' in a new task.

Kanban discourages multitasking as it leads to wastage and inefficiencies. WIP limits in the column boards stress the importance of choosing the work the team has to do at the moment carefully as there is a limited capacity which has to be used efficiently.

Focus on the WIP also helps to reduce the cycle times (The duration from the customer request to the final delivery) for a particular product/service.

Manage the workflow — With the Kanban methodology, the various workflow stages and work progress in each of them are highlighted on the Kanban board.

Kanban emphasizes the management of the workflow process instead of the micromanagement of people with the main aim of its implementation being the smooth work process flow at optimal levels.

This enables the team to analyze the workflow process by measuring productivity/efficiency with metrics like cycle time and lead times. This makes it easier to spot any obstructions in the workflow process.

Most times, these obstructions are in the intermediate wait stages where the work has to change hands, but sometimes other factors like worker efficiency have a role to play.

Wherever they are present, adjustments are made in the work process to remove them and make the workflow better. This will enable the cycle times for the product or service to be reduced, ensuring faster turn around and the delivery of better value to the customers.

Communicate the process policies clearly — A big part of Kanban is the communication of policies and process rules on how work is conducted explicitly to all parties concerned so that there is a clear understanding of what is expected of each person. This help provides a standard against which performance can be measured and ensures quality consistency in the product/service delivered.

There have to be work process rules and guidelines for each column like who pulls what, entry and exit criteria for the column, when a task is done etc. which has to be visualized on the Kanban board. This keeps everyone with a visual reference in the organization as they work towards a common goal.

Get feedback regularly and implement it — Feedback is very important to the Kanban methodology. The review and analysis of the workflow stages on the Kanban board during daily stand up meetings are a good opportunity for this. Each of the different aspects of the workflow like delivery and operations should also be reviewed individually to track their progress.

Team members should also comment on their individual observations during the previous day. These daily meetings should be short and be straight to the point. Plans should be set in motion to work on all the feedback received. Getting all this feedback early in the process enables improvements to be made fast so as to improve cycle times and organizational productivity.

Always experiment and improve — The evolutionary change pattern of Kanban enables the use of the scientific investigation method which involves forming a theory, testing it and modifying it to be better.

The workflow process should be evaluated and improved upon continuously. New techniques can be introduced incrementally into the workflow process and observed, and then a decision should be made to keep or remove them depending on how much improvement they bring to the process through evaluating the metrics measurement.

Sometimes, these techniques just need some modification in order to perform optimally. Continuous improvement is the cornerstone of the Kanban methodology.

The Kanban Process

Kanban is a methodology that seeks to improve an organization's efficiency by applying visualization to the work process. It's based on the proven notion that the brain processes pictures more easily than words. With the visualization, areas of inefficiencies become apparent.

Kanban aims to improve the workflow process gradually and incrementally rather than quickly. This reduces the risk to the organization. It also aims to make the work process flow faster.

The Kanban Board

The Kanban board is the main tool for the visual representation of the workflow process. It enables clearer communication among all parties involved with the way information about the project/development process is highlighted through pictures.

Kanban boards can be in physical forms or in a digital/electronic form which is used for teams with remote members. The Kanban board usually comprises of three main columns:

• To do — Tasks that haven't been started are listed here.
• Doing — Tasks that are being worked on are listed here.
• Done — This consists of tasks that have been completed.

Tasks are represented by coloured sticky notes or cards. By representing the workflow process with pictures on the Kanban board, the efficiency of the workflow process can be measured especially with the aid of specialized Kanban software.

Where efficiency is lower than expected, impediments can be traced and then dealt with. This enables higher production efficiency and shorter product cycle times as well as improvements in the product/service quality.

Benefits of Kanban

Kanban is quickly being adopted by organizations in different industries globally. Some of the reasons for this include the following.

• Clear communication and transparency - The workflow visualization on the Kanban boards enables clear communication and lets everybody involved know what is expected of them. It's easy to track work progress which makes it easy to know what action is needed.
• Spot impediments quickly — The overcrowding of some of the columns can easily highlight where the work process is being slowed down, thereby necessitating adjustments.
• Flexibility — The ability to use Kanban in any system or industry and its philosophy of incremental change makes it a darling among many organizations desirous of continuous efficiency improvements. It is usually combined with agile project management techniques to make them more effective.
• Responsive to demand — Kanban enables capacity to be adjusted to match customer demands avoiding unnecessary wastage as well as the ability to respond to changes quickly.
• Focus and collaboration — Limited work in progress forces teams to focus on WIP instead of multi-tasking thereby enhancing productivity. Collaboration is also enhanced as organizational members help each other to remove challenges in discharging their tasks.

Drawbacks of Kanban

The Kanban methodology has its limitations –

• Ill suited for large projects — Kanban can be challenging to operate in a large scale situation.
• Misuse of Kanban board — The misuse or over-complication of the Kanban board can send the wrong signals about the workflow process which might result in costly mistakes.
• Wild demand fluctuations — Irregular product demands could disrupt the Kanban methodology as wrong signals could be sent as a result.
• Quality miscues— Kanban methodology drives down inventory levels to almost zero in a bid to reduce wastage. But when there's a quality issue with the final product or service, it could be difficult for the organization to react quickly as a result of the absence of an inventory buffer.

Similarities and Differences Between Scrum and Kanban

Scrum and Kanban are the most adopted productivity improvement tools globally but they are not really direct alternatives to each other like most people believe. They have some similarities but there are also differences between both of them.

Similarities

Both Scrum and Kanban are tools to improve productivity and efficiency as well as minimize wastage.

They are both based on the agile project management technique which emphasizes flexibility and ability to adapt to changes.

They also work on the 'pull' scheduling technique.

They both see improvements in product or service quality and delivery times are the cornerstone of both techniques.

They are both based on the self-organization ethos with team members taking their own initiatives and actions with every member being equal to each other and no orders coming externally.

Complex tasks are usually broken down into smaller, manageable parts.

Scrumban

In many organizations today, Scrum and Kanban are being used and combined in what is known as Scrumban. This was originally created for teams transitioning from Scrum to Kanban but has become a project management methodology in its own right. Under this methodology, the Scrum process is used but it's viewed through the lens of the Kanban improvement system.

A board similar to a Kanban board with coloured cards is used. Work is broken down into iterations. WIP limits are used here while team members choose the tasks they will work on since they are self-organizing.

On-demand planning is a feature of Scrumban. This is the application of planning techniques when new tasks are available rather than on a daily basis. Prioritization of tasks is done so that team members know what tasks are important.

Differences

There are many differences between Scrum and Kanban. This includes:

Definition — Scrum is a framework with specific rules and techniques while Kanban is a workflow visualization tool used alongside an existing system.

Training and management — Scrum requires a lot of education and training, as well as management and professionals with expertise. Kanban, on the other hand, can be easily understood by everybody which makes it cheaper to run and manage.

Change process — Kanban encourages incremental change and is suited for organizations with good, stable workflow structures while organizations that need wholesome change quickly should go for Scrum.

Usage — Kanban is usually used for smaller projects while Scrum is more beneficial for larger, more complex projects.

Roles — Scrum has three defined roles of scrum master, product owner and development teams. Kanban has no defined roles as every team member can take up available duties.

Duration — The Scrum process lasts for the duration of the project/development and is started again with a new undertaking while Kanban is a continuous effort as it is done with products/services that have to be continually delivered.

Teams — Scrum advocates cross-functional teams while specialized teams are the norm in Kanban.

New tasks/Iterations — In Scrum, new items cannot be added outside the preplanned tasks for the sprint even when the team has the capacity for such additions. In Kanban, new tasks can be worked on as long as the capacity is available.

Ownership — The sprint backlog in the Scrum process is owned by one Scrum team while the Kanban board can be shared by as many teams possible.

Productivity measurement — Kanban measures productivity using a product's/services' cycle time while Scrum measures this using velocity through the sprints.

Team goals — In Scrum, teams focus on collaborating and completing a pre-defined task while Kanban teams are focused on setting goals and reducing the cycle times.

Conclusion

This article doesn't aim to prove which is better between Scrum and Kanban as they are both productivity tools aimed at boosting efficiency. Rather it is aimed at providing an understanding of both tools so that you can make a good decision if choosing between them – or you can decide to go with both.

I personally prefer Kanban. But I think that's because a mentor of mine gave me a copy of 'Kanban: Successful Evolutionary Change for your Technology Business' which really helped me when I started needing to make my teams productive. It's definitely a book that should be in every office.

If you have any feedback or want to get in touch find me on Twitter @nialljoemaher.

References

https://en.wikipedia.org/wiki/Scrum_(software_development)

https://en.wikipedia.org/wiki/Agile_software_development

https://en.wikipedia.org/wiki/Kanban_(development)

https://en.wikipedia.org/wiki/Scrumban

https://searchsoftwarequality.techtarget.com/definition/Scrum

https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/

https://kanbanzone.com/kanban-resources/what-is-kanban/

https://www.planview.com/resources/articles/what-is-kanban/

https://www.digite.com/kanban/what-is-kanban/

https://getnave.com/blog/kanban-history/

https://www.guru99.com/scrum-vs-kanban.htmlhttps://medium.com/@thorbjorn.sigberg/scrum-vs-kanban-c73dc70e8eefhttps://medium.com/ntask/kanban-vs-scrum-which-one-is-the-better-approach-to-use-in-2018-7503ee98dd0chttps://medium.com/@pavel.obod/kanban-vs-scrum-why-and-how-we-switched-from-scrum-to-kanban-8e524b6619bb

https://www.gliffy.com/blog/scrum-what-it-is-and-how-it-works

https://www.visual-paradigm.com/scrum/how-scrum-team-works/

https://skillcrush.com/2017/06/28/what-is-scrum-project-management/

https://stackify.com/what-is-scrum/

https://www.atlassian.com/agile/scrum

https://www.brighthubpm.com/methods-strategies/71133-weighing-the-disadvantages-of-the-kanban-system/

https://smallbusiness.chron.com/advantages-disadvantages-scrum-project-management-methodology-36099.html

https://www.yodiz.com/blog/kanban-vs-scrum-benefits-similarities-pros-and-cons/

https://leankit.com/learn/kanban/kanban-vs-scrum/

https://upraise.io/blog/scrum-kanban-project-management/

https://www.quora.com/How-similar-or-different-are-Scrum-and-Kanban

Many development teams are too familiar with the frustrations of unsatisfactory acceptance criteria or even the lack of criteria itself. Defining no requirements is like preparing for battle without a plan of action — the team has taken more steps toward failure than success. I offer specific suggestions in crafting acceptance criteria that can improve any agile process.

First, let’s quickly define acceptance criteria.

Acceptance criteria are the “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” (Microsoft Press)

Easy enough, right? Not quite. At this point, I would ask myself if this is where my definition of acceptance criteria stops. In addition to the definition above, any product owner should have answers ready for the following questions:

What do these conditions look like? Who creates these conditions? How many conditions should there be? How are outcomes measured?

Generally, acceptance criteria are initiated by the product owner or stakeholder. They are written prior to any development of the feature. Their role is to provide guidelines for a business or user-centered perspective.

However, writing the criteria is not solely the responsibility of the product owner. Acceptance criteria should be developed as a joint effort between the development team and the product owner.

Crafting these criteria together helps the development team understand the desire featured. It also helps the product owner catch missing details. Additionally, the owner gains a better understanding of feasibility, complexity, and scope.

_Image by [Maryna Z. & Dmiriy G](https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important" rel="noopener" target="blank" title=").

Formatting acceptance criteria

Criteria can be written in a variety of formats. Most teams lean towards two specific types: rule-oriented or scenario-oriented.

Rule-oriented requirements are straight-forward. They list out observable outcomes. “Display statement balance upon successful authentication.”

On the other hand, scenario-oriented criteria tend to follow the “Given…When…Then…” template. This was derived from behavior-driven-development (BDD). This requirement outlines the expected observable result. This occurs when a particular action is executed given some context.

3 characteristics of effective acceptance criteria

1. Testable with clearly defined pass/fail results

Have testable criteria. This allows testers to properly confirm that all of the desired conditions have been fulfilled. If criteria were not testable, then there would be no way for verification. These criteria should either be met or not met. A developer should know the point in which the criterion has been achieved. Any ambiguity may prolong effort on the story.

For example, an acceptance criterion states “increase the number of entries available in a drop-down menu”. The developer would have no idea how many new entries to add and may take the liberty to assume a number based on his experience with the product. Likewise, a manual tester may take the same liberty and assume a different definition of increase. This results in a confusion that will circle back to the product owner.

2. Unambiguous and concise

This is where writing acceptance criteria become an art. Academic essays stress the importance of clarity and succinctness. Similarly, writing acceptance criteria mandates the same level of organization and care.

Similar to writing a literary piece, the audience must be kept in mind. Those reading the acceptance criteria must understand what is written. Otherwise, those words are completely useless. If they are long-winded and filled with jargon, then the main points of the outlined conditions may not come across. Many people can overlook essential details in a sea of words when pressed for time. Even when not pressed for time, many people can easily gloss over long blurbs.

Instead of putting the blame on others’ lack of careful reading, one can proactively present acceptance criteria that are easy to read, straight to the point, and devoid of superfluous details.

3. Establish shared understanding

This is probably the most important characteristic and the one most taken for granted. If all the members of the team are not on the same page, then process and productivity become jeopardized. Having the development team review acceptance criteria before moving forward with the story minimizes confusion. Clarifications should be made about the criteria, and the criteria should be updated accordingly.

I’ve had experiences where all team members have been part of writing acceptance criteria. It allowed everyone to understand all parts of the story. It also provided opportunities for team members to chime in with questions and ideas. However, such a process might not always be ideal, especially for larger teams.

Nevertheless, it is important that each member can read the acceptance criteria. From there each member should gain an understanding of how to bring the story into completion. Regardless of whether it be in development or testing.

When too much is an issue

We’ve already explored the danger of unclear acceptance criteria. This results in the risk of introducing extraneous features into a story. However, the surprising opposite case can also exist: acceptance criteria may become too detailed.

“Acceptance Criteria should state intent, not a solution” (Segue Technologies)

Provide a blueprint of “what” (intention) instead of “how” (implementation). Otherwise, the development team may be robbed of the opportunity to explore different ways to solve the problem. On those lines, better implementations may be thought up after the initial thoughts on a solution.

Once you’ve written your acceptance criteria, you may ask yourself, “How many is too many?”
I’ve seen stories that range from zero acceptance criteria to more than fifteen (or at least it felt like that).

As a rule of thumb, I personally like to see three to eight acceptance criteria per story. However, towards the upper end of that limit, around five or more acceptance criteria, I would check manageability. I would carefully check to see that the story couldn’t be broken up into smaller, more manageable stories.

Others would disagree and argue that eight would already be too many. However, I like to lean towards providing as much “what” detail as I can without sacrificing conciseness.

Now what?

Ok, I lied. I did not provide an exhaustive list of acceptance criteria for writing acceptance criteria. The desired characteristics such as conciseness, clarity, and comprehension are subjective. I intended them to be.

I believe that there is no “correct” format to writing acceptance criteria. Their correctness is measured by the effectiveness in one’s team.

I highly recommend on initially using a template. They have provided many teams with a solid and safe structure that promotes good acceptance criteria writing. However, do not let that structure stop you from advancing into ideas that may promote efficiency and efficacy.

If you are a product owner or client writing acceptance criteria, I challenge you to ask your development team for feedback on the current acceptance criteria. With a bit of care, practice, and organization, crafting effective acceptance criteria becomes a powerful tool in improving the workflow of any team.

More to read

• https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important — by Maryna Z. and Dmiriy G.
• https://www.leadingagile.com/2014/09/acceptance-criteria/ by Steve Povilaitis
• https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ by Segue Technologies
• http://agileforgrowth.com/blog/acceptance-criteria-checklist/ — by Kamlesh Ravlani