• Development Cycle
  • Roles
  • Sprint Calendar
    • Sprints by Release
    • Sprints 1-3
    • Sprint 4
  • Process Points

Development of Open MCT occurs on an iterative cycle of sprints and releases.

• A sprint is three weeks in duration, and represents a set of improvements that can be completed and tested by the development team. Software at the end of the sprint is "semi-stable"; it will have undergone reduced testing and may carry defects or usability issues of lower severity, particularly if there are workarounds.
• A release occurs every four sprints. Releases are stable, and will have undergone full acceptance testing to ensure that the software behaves correctly and usably.

The sprint process assumes the presence of a project manager. The project manager is responsible for making tactical decisions about what development work will be performed, and for coordinating with stakeholders to arrive at higher-level strategic decisions about desired functionality and characteristics of the software, major external milestones, and so forth.

In the absence of a dedicated project manager, this role may be rotated among members of the development team on a per-sprint basis.

Responsibilities of the project manager including:

• Maintaining (with agreement of stakeholders) a "road map" of work planned for future releases/sprints; this should be higher-level, usually expressed as "themes", with just enough specificity to gauge feasibility of plans, relate work back to milestones, and identify longer-term dependencies.
• Determining (with assistance from the rest of the team) which issues to work on in a given sprint and how they shall be assigned.
• Pre-planning subsequent sprints to ensure that all members of the team always have a clear direction.
• Scheduling and/or ensuring adherence to process points.
• Responding to changes within the sprint (shifting priorities, new issues) and re-allocating work for the sprint as needed.

Certain process points are regularly scheduled in the sprint cycle.

Allocation of work among sprints should be planned relative to release goals and milestones. As a general guideline, higher-risk work (large new features which may carry new defects, major refactoring, design changes with uncertain effects on usability) should be allocated to earlier sprints, allowing for time in later sprints to ensure stability.

The first three sprints of a release are primarily centered around development work, with regular acceptance testing in the third week. During this third week, the top priority should be passing acceptance testing (e.g. by resolving any blockers found); any resources not needed for this effort should be used to begin work for the subsequent sprint.

* If necessary.

The software must be stable at the end of the fourth sprint; because of this, the fourth sprint is scheduled differently, with a heightened emphasis on testing.

* If necessary.

• Sprint plan. Project manager allocates issues based on theme(s) for sprint, then reviews with team. Each team member should have roughly two weeks of work allocated (to allow time in the third week for testing of work completed.)
  • Project manager should also sketch out subsequent sprint so that team may begin work for that sprint during the third week, since testing and blocker resolution is unlikely to require all available resources.
• Tag-up. Check in and status update among development team. May amend plan for sprint as-needed.
• Code freeze. Any new work from this sprint (features, bug fixes, enhancements) must be integrated by the end of the second week of the sprint. After code freeze (and until the end of the sprint) the only changes that should be merged into the master branch should directly address issues needed to pass acceptance testing.
• Per-release Testing. Structured testing with predefined success criteria. No release should ship without passing acceptance tests. Time is allocated in each sprint for subsequent rounds of acceptance testing if issues are identified during a prior round. Specific details of acceptance testing need to be agreed-upon with relevant stakeholders and delivery recipients, and should be flexible enough to allow changes to plans (e.g. deferring delivery of some feature in order to ensure stability of other features.) Baseline testing includes:
  • Testathon. Multi-user testing, involving as many users as is feasible, plus development team. Open-ended; should verify completed work from this sprint, test exploratorily for regressions, et cetera.
  • Long-Duration Test. A test to verify that the software remains stable after running for longer durations. May include some combination of automated testing and user verification (e.g. checking to verify that software remains subjectively responsive at conclusion of test.)
  • Unit Testing. Automated testing integrated into the build. (These tests are verified to pass more often than once per sprint, as they run before any merge to master, but still play an important role in per-release testing.)
• Per-sprint Testing. Subset of Pre-release Testing which should be performed before shipping at the end of any sprint. Time is allocated for a second round of Pre-release Testing if the first round is not passed.
• Triage. Team reviews issues from acceptance testing and uses success criteria to determine whether or not they should block release, then formulates a plan to address these issues before the next round of acceptance testing. Focus here should be on ensuring software passes that testing in order to ship on time; may prefer to disable malfunctioning components and fix them in a subsequent sprint, for example.
• Ship. Tag a code snapshot that has passed release/sprint testing and deploy that version. (Only true if relevant testing has passed by this point; if testing has not been passed, will need to make ad hoc decisions with stakeholders, e.g. "extend the sprint" or "defer shipment until end of next sprint.")