Games Project Portfolio - Scrum

As the team Scrum Master it is my job to ensure our sprints and releases are well planned and that that plan is adhered to. I also manage the general workload of the team to ensuring no team member is becoming over burdened with tasks.

Below is a summery of my process of each release and how it has developed over time. There is also a short video for each release giving a brief overview of how the team performed and what worked well.

Follow this link to return to the landing page.

Overview

The initial concept release centered around create solid ideas we could build on for the remainder of the project. Here we focused on planning, prototyping and creating concept art for our assets.

We also put some focus on developing the skills we would need for the project in the future. For example the teams AI lead spent a lot of his time researching AI implementation in Unity so we could jump straight into development during pre-production, which was the next release.

Backlog Items

We had little in the line of a formal process this early in the project. Backlog items were simply generated from team meetings and deciding what we needed to do for the given deadline. This lead to quite a lot of disorganization later in the project, meaning we had to add and remove many different items from the release and sprints to fit with our changing requirements.

An example of this was the addition of multiple play testing items. When we were initially planning we didn't put near enough emphasis on play testing or how long it would take. This meant that we had to add additional playtesting items into the release and also spend more time doing the playtesting sessions themselves due to severe under estimations on how long each session would take (estimated to be 0.5 hours but spiking as high as 3 hours in reality).

Release Planning

For the release we were a little late on the planning with the release, already being a week into the project before we had a release up and running. We didn't lose much as most of our week 1 work was just throwing around ideas for the game. When we did get the release set up we began giving point estimates to all our items using the Fibonacci sequence for estimating. The points gave us a rough idea of how fast we were working and how much work we could complete in a week (this is known as velocity).

As I mentioned in the backlog items section, we had some issues with added and removing different items from the release which had a major effect on our burn-up, shown below.

In this graph the blue line represents the total amount of work planned for the release while the green line represents how much work the team has completed. The spike shown is where we had to put significantly more time into play testing. However at this stage we overloaded ourselves with work, as shown by the drop afterwards. We then moved to cut features from the release to make our deadline. These cuts came in the form of an additional two areas prior to our main level we wanted to include for story purposes. We decided these areas were not completely necessary to the core game and were scrapped to accommodate the bandwidth of the team.

Sprint Planning

Much like our backlog items, we had no formal process for planning sprints this early in the project. Also due to a lack of data I had very little idea of how much work the team could reliably complete within a given time frame. I knew this would improve over time as I gathered data on our performance but it did mean that our initial sprints were quite rough, veering far from an ideal burn-down, as shown below.

Here the dotted line represents the rate at which work should be done throughout the week, while the green line represents when the work was actually done.

A notable issue here is that I was not planning when during the week we would be doing our work. By this I mean that scrum allows me to alter the path of the dotted line to better represent when we plan to do our work. In the case above we had an assignment for another module due early in the week which I knew would slow down our progress, however without proper planning of the burn-down it looks as though the team just got lazy early in the week.

Post Sprint Review

With our sprints ending Friday we always had time after class to discuss how the sprint went and what we could change. This early in the project we weren't making many developments in our scrum strategy with our meetings and they served as more of a catch-up period for the team to recount what they had been working on for the week. 

Results and Improvements

By the end of this release I had figured out how to plan hours to affect the burn-down, which wouldn't be implemented until pre-production.

I also had enough data to start making rough estimations on how much work each team member could do and what days suited them best to work on.

We also had a major decision to make for the next release, to build this as a Desktop or Virtual Reality game.

Overview

The focus of pre-production was to develop a playable "vertical slice" of the level to demonstrate our technical ability and our base mechanics. Our team specifically also had to decide whether or not to develop for Virtual Reality, which would heavily influence our gameplay and mechanics.

I should also mention that I split our pre-production phase into two separate releases in scrum. This was to allow us time to research and decide on Virtual Reality in the first release and then develop for our chosen platform during the second release.

Backlog Items

The first major step we took in improving our planning process was the use of proper user stories. This meant that we looked at everything a user should be able to do in the game and broke that down into the smallest components we could. For example:

Story: 

• The player must be able to complete the level and win.

Items:

1. Modelling Keycards
2. Modelling Power Console
3. Texturing Keycards
4. Texturing Power Console
5. Enabling VR Interaction with Keycards
6. Program slotting Keycards into power console.
7. Audio feedback for correct/incorrect Keycards
8. Audio feedback for power on

There are many more tasks associated with this user story but the list above shows how useful even the most high level story can be in backlog planning.

We also split our tasks into their smallest components to make them easier to estimate. For example "Sound: Door Open" would be split into "Sound Design: Door Open" and "Sound Implementation: Door Open". This had two effects:

1. The smaller tasks become easier to estimate.
2. It provides more data to see what parts of tasks team members are being held up with. Eg: Is the creation of the sound more difficult or its implementation into Unity?

To help organize the backlog a little more I started giving each of our backlog items a prefix to denote what kind of task it was. For example I would have "Modelling - Exterior walls" or "Animation - Robot Walk". This helped identify at a glance how much work was planned for each person in the team. It also helped just to organize the backlog and make it more readable. In the second release, after we adopted Virtual Reality, I also started using scrums tag feature. Similar to the prefixes above they helped add some organization to the backlog, with the helpful addition of colour coding to make it that little bit easier to read.

Release Planning

The first section of this release was quite rocky due to our changing requirements with Virtual Reality implementation as well as a some changing dates and deadlines. Initially the deadline for pre-production was not long after Christmas so I front loaded our sprints to try and get work done early. This proved to only burn out the team and our velocity began to drop, resulting in us having to pull work a lot of work from the release (nearly 100 points worth) to get us to the finish line. I later decided the best option was to split the release, pushing the post-Christmas work into its own release after we had a definite decision on the Virtual Reality. As a result of this we slowly started phasing items out of the release that were no longer required.

Before we left we had a final decision made to go with Virtual reality. We took a two week break over Christmas and I began planning the release in my own downtime. I finished planning for pre-production after meeting back up with the team before we started back to work. To help with planning I also started using a colour coded spreadsheet to divide up work in each individual section, as shown below:

While we only planned for a small amount of work to start with we were given a major deadline extension of about four weeks. This gave us significantly more time to implement new features to the game so we took back to scrum and added in about 100 hours of extra work (25 hours each). With this we could get much more of the level as a whole completed to show off our work.

As work progressed we had found we added too much and we were trying to do work that should be part of the next production release. I made the call to pull a lot of this work out of the release and end it a week early. This gave us a week of pure presentation practice and some much needed down time. I had learned from trying to front load the previous release the importance of down time for the team to catch up on their personal work and relax.

The team performed very well during the presentation due to the practice so I think taking that time off was more important than getting extra work done.

Sprint Planning

With more data available to me on the teams performance (such as how long they spend on specific tasks and what days they're most productive) I could more plan much more accurate and productive sprints. After slowly increasing the workload over time, I found that the teams bandwidth maxed out at about 10 hours a week per person. This made it much easier to plan sprints accurately and made it easier for me to track what team members what ahead/behind schedule on their own work. I do this in tandem with a spreadsheet with each persons planned working hours for each day of the sprint.

With the addition of proper daily burn-down estimations, more accurate backlog item and closer tracking of the teams productiveness on my part, I was able to significantly improve the accuracy of our burn-down charts, an example of which is show below. Again the dotted line represents estimated burn-down, while the green line represents actual burn-down.

Post Sprint Review

For this release I made much more use of our post sprint reviews, showing the team the data I collect on their performance via scrum and seeing where we can improve our planning.

Using this data I could pinpoint specific tasks in a sprint were people dipped in performance or, taking the data for multiple sprints, see trends where people were under/over estimating. In the example above I could extrapolate that I was over estimating my "Texturing" tasks, meaning in the next sprint I could lower time allocated to any more texturing tasks and put that time into work somewhere else. This also works well in conjunction with the tag system as, mentioned above, I can pick specific areas that people are under performing on. 

Burn-down and Results

As shown above, our burn-downs during pre-production were been much more representative of our work and the number of new methods we implemented definitely had a positive effect on our performance. Below is a short list of all the new features I implemented into our scrum during pre-production:

1. Backlog name prefixes and scrum item tagging
2. Better data collection on team performance
3. More productive use of post sprint reviews and use of data collected
4. More structured sprint planning with spreadsheets
5. Use of logging hours on tasks to track time actually spent
6. Better planning process of backlog items (ie: breaking down user stories into small items)

As a side note on point 5, by the end of this release we were logging hours on tasks within scrum however earlier in the release we were doing this on an online spreadsheet. This didn't prove to be too effective as frequently people would forget how long they spent on tasks or completely forget about logging hours entirely. Now logging hours on tasks in scrum shows me exactly where the time goes.

We also developed a rigid process not mentioned above to respond to issues where a person was falling behind on their work. If a team member begins to fall behind schedule it creates whats known as a "Technical Debt". This is where work rolls over from sprint to sprint not being completed until there is no more time to complete it. Below I have listed the steps in the process we go through to address these issues:

1. If the person in question has additional free time in future sprints then the tasks is put on top of what they're already working on, increasing their working time from normal.
2. If the person does not have any free time the task may be offloaded to another team member given they have the required skills to complete it. This is not always an option due to the variety of skills and technical knowledge within the team.
3. If there is no available time within the team to complete a task then we must look at its priority. If it is a high priority task then other, lower priority tasks will be removed from the release to make time for its completion. If it is a low priority task, the task itself is removed.

Overview

While pre-production was about showing off small examples of what we could do, production is about showing everything we can do. Here we completed the entire level and converted the short demo we had in pre-production into a full playable game. The priority here was a working game, so the use of 3rd party assets was more common and testing, even in house, was much more important.

Overall we haven't made any major changes to our planning process from the end of the pre-production stage.

Backlog Items

We continued to use our user story method of planning backlog items and have not changed our process from the end of pre-production. At this stage in the project I found that this method seemed to yield best results with fairly minimum effort.

One obstacle we had was allocating time to bug fixing as it was impossible to estimate how many bugs we could find and how long they would take to fix. To solve this I set a cap on bug fixing time (Jason was taking this on for the most part) to five hours. My plan was that we could get any major bugs fixed in this time, leaving any smaller bugs to be reviewed during post-production. This worked well enough, however we did find one major issue (not being able to pick cards up from the floor) which was just too complex to fix in the time available. This task is more of an additional virtual reality feature we will add to the post-production release.

Release Planning

 The major change I made to the release planning process was the use of hours rather than points. This was done because I could accurately estimate the number of hours work the team could complete each week but points fluctuate considerably as they have no direct link to how long a task would take. As a result of this change we actually finished the release with more work done than we had initially planned (this was also due to the covid-19 lockdown which I expand on further below) and is our first release where I didn't have to remove features last minute to meet the deadline.

As I mentioned, another factor that significantly impacted our performance was the lockdown following the covid-19 outbreak. In the sprint immediately following the lockdown we did see an initial dip in velocity as the team began to adjust to the new workflow. However, once we settled in we actually seen a significant increase in velocity. I estimate this was due to a number of factors:

1. More free time as there was no commuting time in the mornings and evenings.
2. Constant access to home workstations.
3. Lack of classes gave way to more free time to work.
4. Deadline extensions in other modules left more time available for project work.

The most important point here is point 2. There are a number of factors that inhibit or outright prevent some team members from working effectively while in college. These include:

1. Sparse availability of powerful workstations (room 1119 frequently in use for classes).
2. Lack of available study rooms to work in.
3. Difficulties accessing the wide range of software used by the team (Substance Painter, latest Unity version etc...)

And besides these points the each individual team member was simply more comfortable working in their own space with their own machines.

Sprint Planning

There was no major changes to our sprint planning process this release. However I did try organizing the sprints a little more around upcoming deadlines for other modules. This didn't actually have much of an effect as over the last few weeks a lot of our deadlines have been shifting to accommodate working from home. Also the stark change in velocity made it slightly more difficult to estimate what work we could accomplish during a week.

With the changes made by the end of the last release we were able to make much better and more consistent burndowns during production, which was all the more important in these latter stages of the project.

Post Sprint Review

This release was a little different than others in that we were actually more in contact with each other over discord calls than we were in person in college. This meant that post sprint reviews weren't as long nor were they as necessary. This was because the team was constantly updating each other on their progress and issues over the course of the week so by the time the sprint was over everyone already knew what problems we had encountered and what solutions we devised. We actually started leaning into using the downtime at the end of a sprint for some team building exercises like playing games together. With the pressure we were under for this release I would attribute some of our performance to this downtime as it helped keep the team on the straight and narrow.