|
|
| Line 1: |
Line 1: |
| Last Updated 2013.2.22 <span style="color:red">Draft</span>
| |
|
| |
|
| <div class="toclimit-2">__TOC__</div>
| |
|
| |
| <h2>Purpose & Version</h2>
| |
|
| |
| <p>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.</p>
| |
|
| |
| <h2>Overview</h2>
| |
|
| |
| <p>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 visualisation tool on scrum/sprint based projects. </p>
| |
|
| |
| <h2>Candidate Projects</h2>
| |
|
| |
| <p>The Kanban approach can be a good choice for projects that are:</p>
| |
|
| |
| <ol>
| |
| <li>Using continuous or near continuous deployment.</li>
| |
| <li>Reactive projects.</li>
| |
| <li>Projects in maintenance mode.</li>
| |
| </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 kanban
| |
| boards in the traditional manner or you can use them just to visualize what's currently being worked on. It's flexible.</p>
| |
|
| |
| <h2>Accounts</h2>
| |
|
| |
| <p>Please contact XXX@mozilla.com if you need account credentials on kanbanery or if you need to create a new baord.</p>
| |
|
| |
| <h2>Kanbanery Board Overview</h2>
| |
|
| |
| <p>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.</p>
| |
|
| |
| <p>If using kanban there are only 2 'must follow rules':</p>
| |
|
| |
| <ol>
| |
| <li>Visualize the workflow</li>
| |
| <li>Limit work in progress</li>
| |
| </ol>
| |
|
| |
| <p>A full overview of Kanban is outside the scope of this document. Many books have been written, some of them
| |
| are quite good.</p>
| |
|
| |
| <h2>Column Overview</h2>
| |
|
| |
| <p>Columns reflect the lifecycle 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>
| |
|
| |
| <ul>
| |
| <li><strong>Backlog</strong> - Something that 'should be done' ideally ordered by priority.</li>
| |
| <li><strong>Research & Design</strong> - Tasks needing investigation or design work prior to coding. Not required for all tasks.</li>
| |
| <li><strong>Coding & In Progress</strong> - The task is actively being worked on.</li>
| |
| <li><strong>Code Review</strong> - Task complete and is being reviewed. For programming tasks, this is when a pull request has been filed.</li>
| |
| <li><strong>Testing</strong> - Task can be tested by QA or the team.</li>
| |
| <li><strong>Done</strong> - The task is live.</li>
| |
| </ul>
| |
|
| |
| <p>Cards can also be in:</p>
| |
|
| |
| <ul>
| |
| <li><strong>Icebox</strong> - On hold, should not be thought about at this time. </li>
| |
| <li><strong>Archive</strong> - Where completed tasks retire. </li>
| |
| </ul>
| |
|
| |
| <h3>Work In Progress Limits</h3>
| |
|
| |
| <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
| |
| is not available, you can not take on more work.</p>
| |
|
| |
| <p>If you are using kanban you must use WIP limits, they are important!</p>
| |
|
| |
| <h2>Kanbanery Card Overview</h2>
| |
|
| |
| <h3>Task Title & Description</h3>
| |
|
| |
| <p>Use a good title. Description is required for cards not associated with a bug.</p>
| |
|
| |
| <h3>Task Types</h3>
| |
|
| |
| <p>Cards should be categorized by the type of task. Default work types include:</p>
| |
|
| |
| <ul>
| |
| <li>Story</li>
| |
| <li>Feature</li>
| |
| <li>Design</li>
| |
| <li>Bug</li>
| |
| <li>Chore</li>
| |
| <li>Infrastructure</li>
| |
| <li>Documentation</li>
| |
| </ul>
| |
|
| |
| <p>While you can customize the work types, we reommend general types rather than specific or feature based
| |
| (like API) unless those types are relevant for the life of the project. </p>
| |
|
| |
| <h3>Estimates</h3>
| |
|
| |
| <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 lifecycle of the card as additional information about the task becomes known.</p>
| |
|
| |
| <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 bugzilla.
| |
| When creating a card:</p>
| |
|
| |
| <ol>
| |
| <li>Create a bug in bugzilla.</li>
| |
| <li>Enter the bug into the description field of the card.</li>
| |
| <li>All comments / discussion / attachments are entered into bugzilla.</li>
| |
| </ol>
| |
|
| |
| <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 bug. For now, bugzilla is the source of truth for our tasks.</p>
| |
|
| |
| <h3>Priority</h3>
| |
|
| |
| <p>If a card is high priority you can use this field, you may also sort cards by priority order in the columns.</p>
| |
|
| |
| <h3>Owner</h3>
| |
|
| |
| <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>Subtasks</h3>
| |
|
| |
| <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 subtasks should be "Description #BUGID" when appropriate.</p>
| |
|
| |
| <h3>Deadline</h3>
| |
|
| |
| <p>Cards with a hard deadline can have this entered.</p>
| |
|
| |
| <h3>Blocked</h3>
| |
|
| |
| <p>Useful to communicate if a card is blocked by another card or another task.</p>
| |
|
| |
| <h2>Workflow Overview</h2>
| |
|
| |
| <p>The following describes an example workflow for a task. </p>
| |
|
| |
| <ol>
| |
| <li><strong>Backlog</strong> : With some discussion tasks are added to the Backlog and prioritized.</li>
| |
| <li><strong>Research & Design</strong> : Tasks that are being started are moved to this column.
| |
| <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><strong>Coding & In Progess</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>
| |
| <li><strong>Code Review</strong> : Pull request filed
| |
| <ul><li>Non coding tasks or items not needing code review skip this column.</li></ul></li>
| |
| <li><strong>Testing</strong> : Waiting to be tested
| |
| <ul><li>Bugzilla: Task marked as resolved</li></ul></li>
| |
| <li><strong>Testing</strong>: When complete it is marked as <strong>ready</strong>
| |
| <ul><li>Bugzilla: Task marked as verified</li>
| |
| <li>Any task in the QA column marked 'ready' can go live</li></ul></li>
| |
| <li><strong>Done</strong>: For coding tasks this means live</li>
| |
| <li><strong>Archive</strong> : During cleanup phase live items can be moved to the archive.</li>
| |
| </ol>
| |
|
| |
| <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>
| |
|
| |
| <p>There are two places where the <strong>ready</strong> flag is used.</p>
| |
|
| |
| <ol>
| |
| <li>Signaling a task is ready to be coded/worked on.</li>
| |
| <li>Signaling a task has passed QA and is cleared to go live.</li>
| |
| </ol>
| |
|
| |
| <p>Given the above workflow the only columns that should contain <strong>ready</strong> flags are <strong>research and design</strong> and <strong>testing</strong>.</p>
| |
|
| |
| <h2>Future Documentation</h2>
| |
|
| |
| <h3>Github integration</h3>
| |
|
| |
| <h3>Reports & Informing Improvements</h3>
| |