#1 Product Backlog
|
Welcome to my blog and its first post! A short introduction of myself: I am studying game design with a minor in project managment. Currently I am the manager and producer of team Cockatrice and this spring term we are creating a digital game together. In this project we are learning and using the scrum framework which will be the main subject in my blog posts. In this blog I am going to explain how our team have been using the backlog in our work. The first task managers have is to break down the work in order to plan it. That is how it is in the traditional way however, in the agile metholody the work is broken down by the team in collaboration and added to a shared document between all members. This document is called backlog in the scrum framework. The game’s feautures are seperated into the backlog and then broken down into workpackages. These workpackages describe the type of asset such as art, code, design etc. with a brief descripton on what the asset is for example: Enemy #1 special attack.
Now this is all very basic, but why are we doing this? Isn’t one of the agile values working software OVER comprehesive documentation? The backlog is an important facet in the cornerstones of Scrum: the sprint planning and communication. In the sprint plan the asset that are planned are taken from the backlog since it gives a comprehensive overiview on what each feauture needs and which workpackage has higher priority. It also clearly show each team member the work status on each workpackage in the project. The backlog is updated by the scrum master continously showing: A: which assets are done B: what is priority presently in the project C: the changes made throughout the project This is clearly seen in the sprint planning as for example in my team the sprint plan has evolved in each sprint. In the first sprint plan it was very basic and quite short. The backlog wasen’t used propely here and each work group summarised what they were doing. It didn’t truly show from a glance which assets where being worked on. In the following week this was improved, here everything was put into it as it were written in the backlog so it was easier to see the progress in the sprint review. I also changed so hat everything was colorcoded. This helps the members clearly see which is their work as they will recognize that color as their color in the project and don’t have to read through everything to find their work. In the current sprint things have changed once again. Here there are assets planned that were not orginally in the backlog. These assets are workpackages added that are the result from the groups latest design meeting. There some aspects of the game was reworked therefore the backlog and plan changed.
Remember what I mentioned of the agile values? Here you can see the value: Working software over comprehensive documentation. Working software has the higher priority and as the design was changed by the group the documentation followed. It is not rigid in it’s function and when funtioning propely cleary communicate what each team member have dedicated their work hours for in this sprint. Thank you for your time and I hope your week and sprint planning will turn out well dear reader in Game Design.  |
