Webdev/Web Production/Kanban: Difference between revisions
Bsternthal (talk | contribs) No edit summary |
Bsternthal (talk | contribs) No edit summary |
||
| Line 6: | Line 6: | ||
<p>This document is an overview and guide for using Kanban on Web | <p>This document is an overview and guide for using Kanban on Web | ||
Production (WP) projects. WP uses kanbanery.com to host our | Production (WP) projects. WP uses kanbanery.com to host our Kanban boards | ||
and this document contains information specific to their implementation.</p> | and this document contains information specific to their implementation.</p> | ||
<p>WP projects have the option to use Kanban methodology for organizing work. You can use | <p>WP projects have the option to use Kanban methodology for organizing work. You can use Kanban boards | ||
as part of a full | as part of a full Kanban project or as a visualization tool on scrum/sprint based projects. </p> | ||
<h2>Candidate Projects</h2> | <h2>Candidate Projects</h2> | ||
| Line 22: | Line 22: | ||
</ol> | </ol> | ||
<p>If your project is short-term, release or event based you might consider using a mix of Scrum and Kanban. You can use | <p>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.</p> | boards in the traditional manner or you can use them just to visualize what's currently being worked on. It's flexible.</p> | ||
| Line 34: | Line 34: | ||
If you are using a 'scrumban' approach or some other hybrid, please customize to suit your specific needs.</p> | If you are using a 'scrumban' approach or some other hybrid, please customize to suit your specific needs.</p> | ||
<p>If using | <p>If using Kanban there are only 2 'must follow rules':</p> | ||
<ol> | <ol> | ||
<li>Visualize the workflow</li> | <li>Visualize the workflow.</li> | ||
<li>Limit work in progress</li> | <li>Limit work in progress.</li> | ||
</ol> | </ol> | ||
| Line 46: | Line 46: | ||
<h2>Column Overview</h2> | <h2>Column Overview</h2> | ||
<p>Columns reflect the | <p>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.</p> | to match the workflow on your specific project. You should model how your team currently works.</p> | ||
| Line 68: | Line 68: | ||
<p>Set WIP limits on columns where appropriate. These numbers can be changed/updated as you learn | <p>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 | 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.</p> | is not available, you can not take on more work.</p> | ||
<p>If you are using | <p>If you are using Kanban you must use WIP limits, they are important!</p> | ||
<h2>Kanbanery Card Overview</h2> | <h2>Kanbanery Card Overview</h2> | ||
| Line 77: | Line 77: | ||
<h3>Task Title & Description</h3> | <h3>Task Title & Description</h3> | ||
<p>Use a good title. Description is required for cards not associated with an item in | <p>Use a good title. Description is required for cards not associated with an item in Bugzilla.</p> | ||
<h3>Task Types</h3> | <h3>Task Types</h3> | ||
| Line 93: | Line 93: | ||
</ul> | </ul> | ||
<p>While you can customize the work types, we | <p>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. </p> | (like API) unless those types are relevant for the life of the project. </p> | ||
| Line 99: | Line 99: | ||
<p>The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. All cards get estimated | <p>The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. All cards get estimated | ||
and size can change throughout the | and size can change throughout the life cycle of the card as additional information about the task becomes known.</p> | ||
<h3>Bugzilla & Single Source Of Truth</h3> | <h3>Bugzilla & Single Source Of Truth</h3> | ||
<p>Tasks that are non-trivial, require formal QA, involve another group, and/or require public discussion should have a corresponding bug in | <p>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:</p> | When creating a card:</p> | ||
<ol> | <ol> | ||
<li>Create a bug in | <li>Create a bug in Bugzilla.</li> | ||
<li>Enter the bug into the description field of the card.</li> | <li>Enter the bug into the description field of the card.</li> | ||
<li>All comments / discussion / attachments are entered into | <li>All comments / discussion / attachments are entered into Bugzilla.</li> | ||
</ol> | </ol> | ||
<p>Bugzilla is used by everyone at | <p>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 | source of truth for information about a task. For these tasks Kanban is the "when", Bugzilla is the "what".</p> | ||
<h3>Priority</h3> | <h3>Priority</h3> | ||
| Line 123: | Line 123: | ||
<p>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.</p> | <p>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.</p> | ||
<h3> | <h3>Sub-tasks</h3> | ||
<p>A powerful feature of | <p>A powerful feature of Kanbanery is that cards can consist of multiple tasks. These will often have corresponding bugs in Bugzilla. The format | ||
for | for sub-tasks should be "Description #BUGID" when appropriate.</p> | ||
<h3>Deadline</h3> | <h3>Deadline</h3> | ||
| Line 145: | Line 145: | ||
<ul><li>When research & design phase is complete they are marked <strong>ready</strong> with the green checkmark</li> | <ul><li>When research & design phase is complete they are marked <strong>ready</strong> with the green checkmark</li> | ||
<li>Cards that do not require research and design still go into this column and are marked <strong>ready</strong></li></ul></li> | <li>Cards that do not require research and design still go into this column and are marked <strong>ready</strong></li></ul></li> | ||
<li><strong>Coding & In | <li><strong>Coding & In Progress</strong> : Task is pulled into this column and worked on. | ||
<ul><li>Bugzilla: Bug should be assigned to whomever is doing the work.</li></ul></li> | <ul><li>Bugzilla: Bug should be assigned to whomever is doing the work.</li></ul></li> | ||
<li><strong>Code Review</strong> : Pull request filed | <li><strong>Code Review</strong> : Pull request filed | ||
| Line 158: | Line 158: | ||
</ol> | </ol> | ||
<p>The above uses the | <p>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. </p> | into the next column where work occurs. </p> | ||
Revision as of 22:08, 22 February 2013
Last Updated 2013.2.22 Draft
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.
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:
- Using continuous or near continuous deployment.
- Reactive projects.
- Projects in maintenance mode.
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.
Accounts
Please contact XXX@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':
- Visualize the workflow.
- 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
The default size scale includes 0, .5, 1, 2, 3, 5, 8, 13, 21. All cards get estimated and size can change throughout the life cycle of the card as additional information about the task becomes known.
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:
- Create a bug in Bugzilla.
- Enter the bug into the description field of the card.
- 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".
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 a task.
- Backlog : With some discussion tasks are added to the Backlog and prioritized.
- Research & Design : Tasks that are being started are moved to this column.
- 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
- Coding & In Progress : Task is pulled into this column and worked on.
- Bugzilla: Bug should be assigned to whomever is doing the work.
- Code Review : Pull request filed
- Non coding tasks or items not needing code review skip this column.
- Testing : Waiting to be tested
- Bugzilla: Task marked as resolved
- Testing: When complete it is marked as ready
- Bugzilla: Task marked as verified
- Any task in the QA column marked 'ready' can go live
- Done: For coding tasks this means live
- 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.
- Signaling a task is ready to be coded/worked on.
- 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.