My Introduction to SCRUM

Sometimes something comes along that you're excited about but wholly unprepared for how it will change the way you think. Last Summer, I was coming off of an unfulfilling Spring semester, but I was looking forward to the Fall session. I was scheduled to take a few classes with the bright spot on the horizon being a course on Game Programming. I think the gut reaction when people my age see a course on Game Programming is "oh man, I love video games. That sounds fun!" My reaction was probably pretty similar, but I was especially interested in the logic that drove some of my favorite titles. The class would be taught by one of the younger professors, Paul Gestwicki, who I had not had up to this point in my college career. I had heard a lot about how his courses were demanding but very rewarding.

The first day, I knew the class would be different than anything I was used to. Once we had created four socially-constructed teams(we built them based on pre-existing friendships and proximity, not on areas of expertise or ability), we went over the organizational system that we would follow. With around 25 students, all working together, we would definitely need some guidelines to adhere to.

We followed SCRUM, which, by the Wikipedia definition, is:

an iterative, incremental framework for project management often seen in agile software development. 

In plain words, SCRUM incorporates several small teams (four to six people each), with one person designated as the SCRUM Master. Their job is solely to remove impediments, obstacles that are preventing the team from achieving their goals.

The teams work in sections of time called Sprints. Ours typically lasted two weeks, with some modification when holidays would cause the Sprint to end awkwardly.

We had Product Owners, who would create goals called User Stories. These User Stories would be arranged by importance in a Product Backlog. At our Sprint Planning Meeting, which took place at the beginning of each Sprint, we took these User Stories and broke them down into manageable, achievable portions, called Tasks. For example, if the User Story was to create a dialog box for something, a few tasks might be "Create the text for the dialog", "Sketch out some placeholder art for the box", "OK the dialog with a Product Owner".

Pairs of people would volunteer for the task that they were comfortable taking. They would then give their estimate as to how long it would take to accomplish. Every pair was asked to determine their availability in the next two weeks, and volunteer a maximum amount of hours. (This is important because as a legitimate college course, we wouldn't have lectures or labs to attend, so we would need to fulfill the credit hour requirements by working)

This process may appear complicated, but the following flowchart depicts the process from beginning to end, with the goal being to deliver a shippable, high-quality product at the end of every Sprint. If a feature couldn't be finished on-time, it was renegotiated (more on this process later) and left out.

(Image courtesy of Mountain Goat Software)


Typically, time estimates were tallied up and a burndown chart was created. This chart was useful for the teams to see their task progress visually. Also, the chart was useful in retrospectively spotting hiccups in progress. For example, a snow storm might cause the team to lose a bit of production for one day, which could be seen clearly on the chart.

Here is one of our actual digital burndown charts, taken from an old spreadsheet:

The red line indicates steady progress, and the blue line represents our actual day to day progress.


SCRUM Day to Day
Throughout the sprint, "daily" stand-up meetings were held. I say "daily" because many schedules did not sync up perfectly, at least in the Fall Semester, and meetings were held every Monday, Wednesday, Friday instead. These meetings were timeboxed (at fifteen minutes), much like our Sprints, and literally everyone had to stand up. This kept meetings short and focused, with the purpose of the meeting being to inform members of the team as to your progress since your last meeting. Scrum Masters were to pay attention to mentioned impediments during this meeting.

At the conclusion of the meeting, pairs would get to work on their tasks. When the work time ended, each pair was responsible for updating their estimate on the burndown chart. Keeping the estimates up-to-date was imperative for ensuring the burndown was accurate.

If team was going to fail at meeting a deadline for a specific task, it would be renegotiated several days before the end of the Sprint. Renegotiations would take place between the task-assigned team and the Product Owner(s). Sometimes specific requirements might be lessened, but in more extreme cases the task could be dropped entirely. Obviously this is a last resort measure.


This concludes my summary of how I understand SCRUM. While there is a lot to digest here if you're unfamiliar with SCRUM, it all is important. From what I've read, our implementation of SCRUM was pretty true to the standards established by industry professionals. Overall, this development strategy and organizational process suited the project well. Both semesters of development benefited greatly by using SCRUM, but each one did so in very different ways. I'll shed some light on that when I get to the respective semesters.

In my next post, I'll talk about the game, how software development with 25 other people (college students, no less) can be difficult but rewarding, and how SCRUM and Agile methodologies made it all work.