Cappin' Stones (11/2/2016) Part 3

I am now a Certified Scrum Master. Or, I will be, once I am sent the test to take. I spend the last weekend in a 16 hour Scrum training session, and I learned about so many ways we could improve our work load and scheduling.

We had been using Scrum at Champlain College in various sorts of capacities. The way we log hours and organize our projects uses Redmine, a team organizational board that features a Project Wiki, a task board, point and time estimates, and the ability to make and assign user stories. But the way we had been taught Scrum left a lot to be desired. It came after classes where teams collaborated on smaller games and were told to just meet up and work on specific parts of the project until it comes together. It came down to the team to determine what was most needed and what would work the best, and often communication errors or people missing meetings left people in the dark about what was going on. It wasn't until around Sophomore year that I recall hearing the word Scrum, and the concept of logging hours for tasks you did, and the ideas of User Stories were hastily explained to us. It felt like a chore, an extra layer of busy work that we "had to do because the industry does it", and looking back, not only was the way we were taught confusing, the way that it was implemented in practice for teams was confusing. There was no real reason for people to use User Stories, or have daily Scrums. Classes were structured in a way that we had deliverables due ever x number of weeks, so people just worked on what they needed to do in order not to fail, and everything was fine. With something more flexible as Capstone, where teams can get in and out of stages whenever they are ready, Scrum starts to make sense.

But what is Scrum? It's a organizational strategy where larger teams are broken up into small groups, or a team just acts as a small group. Before work starts, the team gets together and breaks down what they want to accomplish as a big picture for the game. For our game, the big picture ideas are: a rhythm system that feels natural to move with, security systems that act as blocking agents to the player, and levels to play in. Broken down, these three objects would become User Stories, written from the perspective of the user of the product. These three goals would ideally be broken down further, but as point of reference, they would show up in our Project Backlog, a list of things needed, listed in order of priority or difficulty, as this:

"As a Player, I want a rhythm mechanic so that I can move to the beat and feel in control of my actions."

"As a Player, I want obstacles, and challenges so that I may have challenge in this game"

"As a Player, I want levels that are designed around obstacles, so that I have clever puzzles to solve"

These user stories would then have tasks underneath them, created when the stories are, breaking each section down. For the rhythm mechanic, not only would we need to code the rhythm mechanic, but also design the buffer zone around it, test it, and iterate on it. Sound designers would need to create sounds for the beat, as well as other objects in order to sell the rhythm movement, while artists would need to create art assets that can visually communicate the beat and rhythm movement. Each of these pieces would be added as tasks to the task board underneath stories. After that, a meeting would occur where people volunteer to work on certain stories and tasks. Nothing is assigned to people.

Every day after that, until the end of the "sprint" a 1-3 week long session where people try to accomplish all that was set out in the volunteer meeting, a daily 15 minute meeting is held where people are asked what they have been working on, what they will work on, and if there are any roadblocks that other team members can help with.

In a business setting, all of the above is perfect, but in a school setting, things get a lot more tricky. Differing schedules, residences of team members, and time flat out makes a regular Daily Scrum meeting impossible. I'm looking into ways to hold digital Daily Scrum meetings in order to help solve some communication issues. But the rest of the Scrum methodology is incredibly useful, heading into the last stretch before presentations.

By setting out what is left as stories, and having people take responsibility of stories, we can organize what we are doing on a week by week basis much easier. Previously we would have a weekly meeting where we talked about what needed to get done and people said "Oh, I'll do this" but ended up working on other tasks that seemed more important as they came up. By having people stick to a rigid schedule of what they are doing each week, we can avoid feature creep and people working on things that aren't important. In our meeting, later tonight, we will be creating user stories for the rest of the project and assigning stories for this next week. Scrum will be a major asset going forward. Our game is so close to being done, we just need to push it for the rest of the home stretch.