Webdev/Web Production/Kanban

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, the below is just a suggestion. 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. Only items that should actually be worked on should be added to this column.
  • Ready Flag: None. Tasks are assumed ready.

2. Research & Design

• Tasks that require additional steps before being actively coded are pulled to this column.
  • Ready Flag: Flag applied when task is ready. If no R&D needed task can skip this column.

3. Coding & In Progress

• Task is pulled into this column when actively being coded/worked on.
  • Ready Flag: Pull request filed or for non-coding ready for review.

4. Code Review

• Task is pulled into this column by whomever is doing the Pull Review.
  • Ready Flag: Task is merged (PR+), will be on dev at next automatic push. For non coding not used.

5. Testing

• Task is pulled into this column by whomever is doing the QA, either team members or QA. Non coding tasks may skip this column.
  • Ready Flag: Passed QA can go live at next push.

6. Done

• Pulled to this column upon deployment and verification in production environment. For non-coding the task is done.
  • Ready Flag: Not Used

Future Documentation

Reports & Informing Improvements

Github integration