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 our 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.


 * 1) 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 serve as a high-level reminder of our current commitment, and tasks are usually subtasks of these goals.
 * 2) 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.
 * 3) Upcoming - Once a task is analysed, it can be placed in the upcoming column. This column signals that a task ready for estimation. Once a task in this column has been estimated, it can be placed in the next column.
 * 4) Ready for Development - Tasks in ready for development can be picked up by an engineer. Once someone claims the task, it can move to "doing".
 * 5) 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".
 * 6) 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 on the visual or interactive elements.
 * 7) Code review
 * 8) Needs more work
 * 9) QA
 * 10) QA in prod
 * 11) Ready for Signoff

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.