To anyone outside the realm of Scrum the idea of a Product Owner makes sense. They are the person who has full control over the product, and then by extension all the responsibility. However, this is not entirely the case in the Scrum framework. The Product Owner is the one who has the vision for the product which means they are responsible for making sure the team creates the right product. They do this through prioritizing the features the team works on first, and making sure the feature list is up to date.

Each user story is also important in that it is a way to present a feature in a language that anyone can understand. This is useful for when talking to the team since they can all easily estimate how many Story Points to assign to a feature. Story Points are relevant only to the development team and represent how “big” a story is compared to others. The exact scale of one story point is determined by the team through working with each other, understanding how each other works, and what both of those mean in combination to each other. Until this past week our team didn’t have any of these components.

This last weekend I had the wonderful opportunity to take part in a Product Owner Certification course run by Clinton Keith. This course is a little unique in that it is primarily directed towards use within a game development project. While I had already taken the Scrum Master Certification course last year, this past weekend opened my eyes up to how large of an opportunity cost I had undertaken with my team in not implementing three aspects I talked about in the opening paragraph: a Product Owner, proper User Stories, and Story points. In turn we’ve made some subtle changes and major changes, so for this post I’ll be going over that in detail.

We had all the other artifacts of scrum but I was worried since we didn’t have a single game concept yet. Instead we had three that would each require their own sets. I thought it too much overhead to implement these artifacts so early on. Looking back however I realize that we could have started implementing all three from the very beginning.

First off was that out of all three of our ideas it was clear early on which one we were leaning towards: 0g. Additionally, both Tyler and Alana had a lot of faith in Richie to point us in the right direction for all our concepts. With these in mind I could have easily suggested we made Richie the product owner for all three concepts. This would have given us more structure in those first few weeks while gaining a better understanding of our team dynamics.

For the other two it was more of an error on my part. Looking back there was an early understanding among the team on how much work they could do within a week. In addition, User Stories might be complicated to grasp in the beginning, but people only get better at it over time and cause a deeper level of understanding across the team. This would only help us at the point we are at now where we are trying to get all aspects of the game into the product backlog using User Stories. We would be better at making them and defining them.

Story Points are highly subjective to the team and as a result require time to form a definition for. The team could also have used Story Points early on to do several things: be more accurate in their estimates, properly start measuring velocity, and get a better understanding of where we are in relation to Capstone. This would put us in a more structure point compared to where we are now and allow us to plan more easily.

However, we didn’t have any of these Scrum Artifacts and this is something that came at me head-on over the weekend. While I was sitting in the course I kept thinking of what we needed to do to utilize these for the team’s success. The result of this was making Richard Conti, our designer, the product owner and to have a meeting where we estimated some Story Points from past tasks to get a hang of the process. This then allowed us to estimate our current backlog, which already had proper user stories in a prioritized order. This meeting was longer than our usual weekly Tuesday meeting but now we are in a position as a team to properly plan as much as possible while keeping our team flexible to change.

But I don't think student projects aren't doomed, far from it, they just need to take the above into account when working on a project. Students need to realize that their games can't and won't ever reach the levels a studio project can get to. They need to learn to scale back their ideas, lower their expectations, and manage themselves in a way tailored to specific projects. As the project manager for student projects this is a primary concern of mine going into Capstone.

Thank you for reading!