Webdev/Web Production/Kanban

Last Updated 2013.4.19

Introduction

This document is an overview and guide for using Kanban on Web Production (WP) projects. WP uses kanbanery.com to host our Kanban boards and this document contains information specific to their implementation.

Note this is a general guide and intended as a good starting point. It is expected that each team will develop a process tailored to what works best for them.

WP projects have the option to use Kanban methodology for organizing work. You can use Kanban boards as part of a full Kanban project or as a visualization tool on scrum/sprint based projects.

Candidate Projects

The Kanban approach can be a good choice for projects that are:

1. Using continuous or near continuous deployment.
2. Reactive projects.
3. Projects in maintenance mode.
4. Projects that need to adjust work during a 'sprint'.

If your project is short-term, release or event based you might consider using a mix of Scrum and Kanban. You can use Kanban boards in the traditional manner or you can use them just to visualize what's currently being worked on. It's flexible, use the tool that works for you and your team.

Accounts

Please contact bsternthal@mozilla.com if you need account credentials on kanbanery or if you need to create a new baord.

Kanbanery Board Overview

This overview assumes you are using a traditional Kanban workflow to manage your projects. If you are using a 'scrumban' approach or some other hybrid, please customize to suit your specific needs.

If using Kanban there are only 2 'must follow rules':

1. Visualize the workflow.
2. Limit work in progress.

A full overview of Kanban is outside the scope of this document. Many books have been written, some of them are quite good.

Column Overview

Columns reflect the life cycle of a task. WebProd projects are given default columns. You can adjust columns to match the workflow on your specific project. You should model how your team currently works.

• Backlog - Something that 'should be done' ideally ordered by priority.
• Research & Design - Tasks needing investigation or design work prior to coding. Not required for all tasks.
• Coding & In Progress - The task is actively being worked on.
• Code Review - Task complete and is being reviewed. For programming tasks, this is when a pull request has been filed.
• Testing - Task can be tested by QA or the team.
• Done - The task is live.

Cards can also be in:

• Icebox - On hold, should not be thought about at this time.
• Archive - Where completed tasks retire.

Work In Progress Limits

Set WIP limits on columns where appropriate. These numbers can be changed/updated as you learn what works best for the team. For coding a good start is 2 items in 'coding' at a given time per developer. If an open slot is not available, you can not take on more work.

If you are using Kanban you must use WIP limits, they are important!

Kanbanery Card Overview

Task Title & Description

Use a good title. Description is required for cards not associated with an item in Bugzilla.

Task Types

Cards should be categorized by the type of task. Default work types include:

• Story
• Feature
• Design
• Bug
• Chore
• Infrastructure
• Documentation

While you can customize the work types, we recommend general types rather than specific or feature based (like API) unless those types are relevant for the life of the project.

Estimates

Estimates in Kanban are much less important than in Scrum. However you should still estimate tasks in the backlog as a general reflection of total effort.

The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. For example:

• .5 - text change
• 2 - change to code, pull request review
• 5 - significant changes to code, multiple files, requires formal QA, possibly other teams
• 21 - large task involving significant investigation, coding, QA, involves multiple teams

Try to have tasks that are generally the same size, tasks that are 5 and above can usually be broken into smaller tasks.

Bugzilla & Single Source Of Truth

Tasks that are non-trivial, require formal QA, involve another group, and/or require public discussion should have a corresponding bug in Bugzilla. When creating a card:

1. Create a bug in Bugzilla.
2. Enter the bug into the description field of the card.
3. All comments / discussion / attachments are entered into Bugzilla.

Bugzilla is used by everyone at Mozilla and our community. We want to keep our projects and tasks open. We also need to have a single source of truth for information about a task. For these tasks Kanban is the "when", Bugzilla is the "what".

Kanbanery does have an issues tab, however we recommend that you do not use this for either storing the primary bug or any sub-tasks (more below).

Priority

If a card is high priority you can use this field, you may also sort cards by priority order in the columns.

Owner

Owner can either be assigned manually or it can be assigned automatically. If you pull a card into a column it will be assigned to you.

Sub-tasks

A powerful feature of Kanbanery is that cards can consist of multiple tasks. These will often have corresponding bugs in Bugzilla. The format for sub-tasks should be "Description #BUGID" when appropriate.

Deadline

Cards with a hard deadline can have this entered.

Blocked

Useful to communicate if a card is blocked by another card or another task.

Workflow Overview

The following describes an example workflow for WebProd tasks. Sites are encouraged to develop a flow that fits their specific need. For example: mozilla.org

1. Backlog
   • With some discussion tasks are added to the Backlog and prioritized.
2. Research & Design
   • Tasks that are being started are moved to this column.
3. Research & Design: Ready
   • When research & design phase is complete they are marked ready with the green checkmark
   • Cards that do not require research and design still go into this column and are marked ready
4. Coding & In Progress
   • Task is pulled into this column and worked on.
   • Bugzilla: Bug should be assigned to whomever is doing the work.
5. Code Review
   • Generally this means pull request filed
   • Non coding tasks or items not needing code review skip this column.
6. Testing
   • Waiting to be tested
   • If a coding task: Code is testable on dev or stage.
   • Moved into this column by whomever has done the work
   • Bugzilla: Task marked as resolved by whomever did the work.
7. Testing: Ready
   • When testing is complete task marked as ready with the green checkmark.
   • Usually done by QA
   • Bugzilla: Task marked as verified by whomever QAs
   • Any task in the QA column marked 'ready' can go live
8. Done
   • For coding tasks this means confirmed live
   • Usually moved into this column by a developer or PM
9. Archive
   • During cleanup phase live items can be moved to the archive.

The above uses the Kanban 'pull' methodology. Tasks are marked as ready, signaling that it can be worked on. The task is then pulled into the next column where work occurs.

There are two places where the ready flag is used.

1. Signaling a task is ready to be coded/worked on.
2. Signaling a task has passed QA and is cleared to go live.

Given the above workflow the only columns that should contain ready flags are research and design and testing.