Morgan's First Sprint of Spring

Last Friday was the end of Sprint 8 on the Morgan's Raid project. This was the first sprint of the Spring semester. The "closers" are a team of eight CS majors and our one Honors Fellow from Art. The team were selected from among the 25 developers in Fall's CS315 class. These eight were among the top students in the Fall, and not all were from one team. I am not loaded for running the project this semester, and so I had to limit the number of students I could take on to what I could comfortably manage in my regular assigned research time.

During Sprint 8, we crossed the 1000th changeset, and as of this writing, we're at revision 1037. We had a pizza party at the end of the sprint to celebrate, and I promised the team we would do it again on every order of magnitude. I wonder if Papa John's will still be having their $10 large deal when we hit 10,000?

For Sprint 8, we budgeted 80 hours, assuming each student would work 10 hours per week and that most work would be done in pairs. Unfortunately, I had forgotten about Martin Luther King Day when we did the planning meeting, and so we were actually overcommitted when one considers that we lost a working day. Still, the sprint went quite well, and I think the team did a great job of estimating their tasks, including difficult design tasks such as revising the raiding system through multiple paper prototypes.

Since we have a dedicated space (hooray!), we moved off of Google Docs as a platform for managing the Product and Sprint Backlogs and are now using a whiteboard and Post-It notes. I think the only feature we miss from Google Docs is the automatic updating of the burndown chart based on updated estimates of effort remaining. (This also gives me an incentive every two weeks to post our burndown charts here, so that I don't lose my digital copies.)

The other major change we made was to modify the Sprint Backlog format. In the Fall, teams broke down user stories into tasks and then marked their estimates of hours remaining after each working unit. Whether a task was not yet started, in-progress, or finished was implicit in the numeric value and slope. One of the prominent weaknesses articulated by the team in last semester's retrospectives was the need for more formal validation, and so this sprint, we have a backlog in this format:

User story	Tasks not yet started	Tasks in progress	Requires validation	Done

Formalizing the need for validation helped in Sprint 8, although in the retrospective, we realized that we needed more careful articulation of whose validation was required. With multiple product owners and tasks of varying technical complication, it was not always clear who was the appropriate person to contact. However, I do think that losing Monday to MLK day was a major factor here.