Thalia Roadmap
Sprint phase: |
Sprint 6a - Release eng: Robin
|
Sprint 6b - Release eng: ? |
sprint planning
- product owner picks focus, features, and bugs for next sprint, moves to a new sprint bucket in JIRA
- all: may nominate candidate bugs and features for sprint
- all: look at sprint bucket in JIRA and make estimates for their tasks
- all: separate design and implementation for new features when entering issues in jira
- Product Owner prioritizes items for planned work.
- sprint planning meeting:
- Choices for planned work are reviewed by team
- Release engineer chosen
- Required design meetings are identified and planned/scheduled
|
3/21 - 3/27
planning meeting: 3/27 |
3/21 - 3/27
(one planning for all of sprint 6)
|
development and design cycle
- dev: starts coding on clearly defined features
- dev: facilitates required design meetings, and documents final design choices so QA can prepare test plans, know what to expect with new features
- qa: starts testplans
- scrum master: produces burndown chart
- ongoing releases to test environment as needed, to be negotiated between dev and QA
- New features / planned work first;
- Last week of cycle is for bug backlog
|
3/31 - 4/11 |
4/11 - 5/23
* will overlap with bug fixing for sprint 6a |
first release to qa
- release engineer or dev: releases to QA machine
- dev: code is branched, and all new development occurs in a that sprint's branch
- dev: if there is time before issues related to immediate build come in, start bugfixes from backlog
- QA: test plans complete, testing of planned work begins
|
4/22
|
5/26
|
iterative qa phase
- dev: work on bugfixes for planned work
- qa: verifies backlog fixes, and fixes as specified in each version's release notes
- customer relations: sends an early notification to thalia-info
|
4/22 - 5/1
|
5/26 - 6/13
|
QA makes recommendation about release -- team decides go/no go for proposed production release date
- qa: all fixes verified, no blockers
- customer relations: sends an imminent release announcement to thalia-info 24-48 hours before release
- release engineer: 24 hours before release, notify server ops of service outage
|
5/1
|
6/13 |
release to production
- release engineer and ops: release code - release window is a Tuesday or Wednesday, 6PM-9PM
- release engineer: send confirmation to server ops that release was successful
- customer relations: send confirmation to thalia-info that release was successful
|
5/6
|
6/17 |
---------------
Post sprint organization...
Dev Freeze = no new feature development. Developers shift to fixing bugs.
Code Freeze = current dev branch is completely frozen prior to deployment. All new dev work goes on a new branch for the next iteration.
Release date - generally, we aim for deploying on a Tuesday morning, so that folks are actually around if something breaks.
Sprint Number |
Dev Freeze Date |
Code Freeze |
Release Date |
Release Engineer |
1 |
September 21, 2007
|
October 12
|
October 15/16
|
Robin |
2 |
October 29, 2007
|
November 1
|
November 5
|
Janet |
3 |
December 3, 2007
|
December 10 |
December 13/14
|
Qing |
4 |
January 4, 2008 everything except access control
January 11, 2008 code freeze
|
Jan 25, 2008 |
Jan 29, 2008 |
Janet |
5 |
March 11 2008 dev code freeze
|
March 18, 2008
Arnis sent out the customer announcement
|
March 25, 26, 2008
Arnis sent out the service outage note the day before the release
and reiterate the major features in this release |
Qing |
Pre-sprint organization
Oct 2 Usability test
Oct 19 code freeze
Nove 19 release