Blog Post #1 – Managing the Product Backlog

Welcome to my very first Blog entry. I am the project manager and producer of team Amarok. Currently we are creating a shoot´em up videogame that uses the concept document “Burn Witch Burn” as a starting point. My work within the team consist mainly of managing the team, designing gameplay elements together with the lead designer and creating sound files.

This week I want to talk about the product backlog. This has been the very first task that our game design team Amarok got assigned with, for our current Game Project.  The product backlog contains a sorted list of artefacts and assets that need to be created for the game, starting out in the pre-alpha phase and ending with the gold master, the end product. As the producer of the team I was mainly responsible for the product backlog and it´s correct implementation, as well as making sure that the document is always up to date. It was the first time that I worked with the agile method scrum and a product backlog list, which made it a bit more challenging than anticipated.

Firstly, I sat down with the team and we broke down the main artefacts of the game. An example of that would be the main character, the witch Gilli, which got divided up into the several sprites and animations that are needed from the artists, as well as the projectiles and power-ups. From the programmers we needed code that would dictate her movement, rotation, projectile behavior and the likes. Additionally, there were the sound files that needed to be created, as well as a design document by our lead game designer to communicate and document the main design choices.

product-backlog-old
Product Backlog first draft

The mistake I made in the beginning though, was to group the backlog by type instead by feature. This made it harder to see if all necessary artefacts were included in the backlog, since one had to constantly scroll up and down in order to compare the code, art and sound artefacts. Therefore, I didn´t notice that we were still missing crucial player feedback artefacts, such as death animations of the main character and the enemies.

After realizing that the current sorting of the product backlog was too confusing, I changed the order completely and sorted by feature instead. Now we had a better overview of all artefacts necessary for every single feature and I added the missing player feedback as a result. Afterwards, I added the risk level of the artefacts with the help of the expertise of my team members, since I felt that they have a better idea of how high the risk for every single item they are going to create is and I trust their judgement.

product-backlog-new
Product Backlog latest draft

Lastly, I added the priority levels of every single artefact ranging from high alpha to low beta (highest to lowest priority) and a specific deadline. Since we are using an agile method to manage the project and there are always events that can impact the weekly sprints, things like the deadlines and priorities are always subject to change and make the product backlog a living document, meaning it has to be constantly updated.

This concludes my blog post for this week. If you want to find out how my adventure with team Amarok continues, just revisit the blog next week!

Advertisements

One thought on “Blog Post #1 – Managing the Product Backlog

  1. Hi Marcel!

    I enjoyed reading your first blogpost! Your language is clear and easy to follow and I think you have done a great job describing the work process of creating a useful backlog.

    You start off with a short introduction to the project and your role as a project manager and producer. That gives me as a reader a background to your task and why you have had to do it, as well as putting your task to a context, good! To improve this section even further, maybe you could have mentioned briefly how the backlog is supposed to be used throughout the project, by picking artifacts to work on in each sprint etc.

    I think your presentation of how you went about to create your backlog is direct and you picture the work flow nicely. It brings extra value to the text that you describe the problem you encountered, with the sorting of artifacts, and how you managed to solve it. The pictures too illustrate the problem and what difference it made to change the categorization of the artifacts.

    In summary, an excellent job!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s