Readers/Web/Team/Development cycle

The Reading Web Team develops software in two-week long sprints, or iterations. During the course of a development iteration, planning occurs for upcoming iterations.

Rationale
The team works in such a fashion in order to:
 * Keep the cost of change low (in all facets of the project - requirements, personnel, practices, etc)
 * Minimize risk by iteratively prioritizing requirements, closely examining/reevaluating the evolution of the product with the product owner and key stakeholders
 * Rapidly make adaptive changes as the product evolves
 * Increase productivity/limit context switching by focussing on a limited scope of small, manageable, discrete chunks of work
 * Measure and evaluate team capacity to aid in realistic estimation and create realistic expectations
 * Maintain a sustainable pace by limiting scope to the team's capacity

Kanbanana board
The Web team's current work is captured on the sprint board (affectionately known as the kanbanana board). The Sprint board is comprised of the following columns. The board is designed in Kanban fashion where tasks move from left to right as they are being worked on.

Tasks in all columns are prioritized via colors as well as their position in each column (tasks at the top of the column are higher priority than those near the bottom of the column). The product owner sets the priority on most tasks, and engineers should generally pick up tasks closer to the top of the column.

Quarterly goals


 * This column lists all the current goal for the quarter. Tasks in this column are usually marked with [GOAL] or [EPIC]. These tasks do not move through the board like regular tasks (they usually stay here until the end of the quarter, when they can be placed in ready for sign-off if completed). They serve as a high-level reminder of our current commitment, and current tasks are usually subtasks of these goals.

Needs analysis


 * Before a task is ready to be worked on, it is typically put in the "needs analysis" column to be scoped by an engineer. This process involves taking a preliminary look at the problem and documenting the most likely approach for the problem.

Upcoming


 * Once a task is analysed, it can be placed in the upcoming column. Tasks here are waiting for estimation. Once a task has been estimated, it's ready to be moved to the next column.

Ready for Development


 * Tasks in ready for development can be picked up by an engineer. Once someone claims a task, it can be moved to "doing". Tasks are prioritized with colors as well as the order in the column (i.e. tasks at the top of the column are the highest priority).

Blocked on others


 * If a task is analysed, estimated, but waiting for input or work from an external team, it can be placed in "blocked on others" until it is ready to be worked on. From here it can go back to "ready for development" or "doing".

Design review


 * When a task is in progress but requires some design guidance, it can be placed in this column, usually with a link to a demo showcasing the work in question, or a screenshot. At this point in the cycle, the patch may need refinements of visual/interactive elements, and the engineer should work collaboratively with the designer to resolve any design issues or questions.

Code review


 * Once a task has been worked on and a Gerrit patch has been submitted, the task should be placed in code-review. This allows other engineers to know what needs review and assign themselves to tasks they feel most capable of reviewing.

Needs more work


 * When a task has been code-reviewed but requires further modifications, it's placed in this column as a signal to the original developer that the patch needs updating. The original developer may then continue to push modifications to the patch and place the task back in code review when updates are ready. Whether or not the task should be placed in "doing" while the updates are being worked on, is and will remain, a perennial question for the web team.

QA


 * Once a patch has been merged, it should be placed in the QA column for the QA engineer. Before placing a task in the QA column, ensure that it has QA steps and Acceptance Criteria in the description, outlining what steps should be followed to test the patch (including any specific browsers, languages, environments etc. if necessary) and what the accepted outcome of those steps are. QA is usually done on the beta cluster unless specified otherwise.

QA in prod


 * Because life is hard and wikis are complicated, sometimes we need to double check the work when it's deployed in production. This lets us catch bugs related to gadgets, user scripts, and differing wiki configurations that are not available on the beta cluster.

Ready for Signoff


 * And finally, once a task passes QA it can be placed in "ready for sign-off" for one last look before it's resolved.

Regular Rituals
There are a series of regular meetings to facilitate iteration planning. They are strictly timeboxed and facilitated by the scrummaster. Regular planning meetings are open to all, but are mandatory for some. The regular meetings are intended to balance the need for planning activities against the need for head's-down focus time for everyone on the team, and ultimately minimize the amount of expensive context-switching everyone on the team is exposed to.

This table captures the particulars of all regular planning meetings. Specific days of meetings are subject to change for scheduling conflicts, holidays, etc. Attendees are invited via Google calendar, where the definitive date/time of meetings is maintained.