Collection: GD4 TP2 Portfolio



Scrumwise is an agile development tool used to manage a team or solo project to ensure all requirements are met and on schedule. My role as scrum master for our games' development was to plan and facilitate this streamlined working method. 

The most important points of this role were at the release planning stages. For a release, our team has to plan everything that would be done in advance. My approach to ensuring this was done well for Alpha was for us to firstly consider on a high level each area that needs work. These areas would then be broken down into general objectives to complete. These objectives were then broken down and clarified so we all know exactly what it was that was to be done. This was then taken and broken down further into steps and tasks needed to be done for that objective to be completed. This process was applied to all areas of the game, and these steps would then be turned into stories on scrum. Release tasks are roughly estimated in points of perceived effort. These estimates would be made by the specialist in that area, but this estimate would then be queried by the group to ensure that firstly everyone understood the tasks but also to ensure the person wasn't over or underestimating their work. I didn't try to make it so that I was setting up every task, because it made much more sense to me for everyone to be setting up the tasks together simultaneously. This is one of the most useful features of Scrumwise in my opinion. The picture below is a screenshot I took the day we were setting up the release. We were all in our meeting together working on filling out the backlog with the work we had planned as a team, and this streamlined the planning process considerably, as it was just an on-going discussion as the backlog got filled out. 


Our team has a weekly scrum meeting, where we plan each weeks' work in advance. This was not a particularly difficult thing to do as the majority of our team is in constant contact as is. Furthermore, because we plan all the work for each release in advance, weekly sprint meetings were fairly simple and relaxed. Each team member would pull the work they were going to do for that week onto the sprint, they'd give an estimate for each task, and the team would discuss the accuracy of this estimate. If there was ever any confusion about a task, it would be cleared up and settled, and then added to the sprint. Generally though, because the tasks were already there and ready to go onto a sprint, the weekly meetings were over with quickly. The tasks are estimated again in hours before being added on, and while it was by no means a rule, I found that aiming for roughly 10 hours per person per sprint was an acceptable pace for us to work at while still getting work done in good time. 

PoC Release


Alpha Release


Release Comparison

For the entirety of our PoC release, our team worked a little bit fast and loose. We didn't really take the time to truly plan the details of what it was we wanted to have achieved by release time, we just had end goals in mind without any steps shown on how we were going to get there. We made many large vague scrum stories to give ourselves freedom to work without constraints, but this is not how Scrum is supposed to work. While we definitely achieved all we wanted to and more for PoC, we were really just lucky that we're such a coherent team, because the way we were working had a lot of potential for a huge collapse in development. This was pointed out to us, and we definitely took the criticism on board. We didn't just turn heel and jump through the hoops however. We sat down as a team and looked at what we were doing wrong critically, and we questioned the criticism thoroughly as well. We arrived at a new way for us to work, which we felt was a good compromise. 

The fruits of this change can be seen the difference in shape of the two release curves. While PoC has very cliff faced jumps, Alpha has a comfortable hill climb. This gradual pace allowed us to more easily see if we were on schedule, which aided in the decision to add more work half way through the Alpha release. Overall, we're happier now with the way we work, and will continue with our new approach for Beta.

Sprint Details

Due to the nature of our timetable, it's a simple fact that the most time we have free as a group is in the last few days of our sprint. However, I've always made it a point to at least aim to get a decent amount of work done before this, to avoid any sort of panic or compromise on the quality of our output. This has generally worked out fine. 

Another point to make is that for each release, a decision I put forward that the team agreed with from the start, was that we aim to be basically finished with the actual work in a release before the final sprint, so that the last sprint can then be used for tidy up, sorting out presentations and preparing for submission, along with taking care of any glaring issues if they happen to have arisen. This approach has worked well for us. We don't feel a lot of panic coming up to the delivery because everything has generally been taken care of well in advance, and despite preparing for trouble, it hasn't really came up yet in a major way, medical issues with team members not withstanding. 


Firstly, I'm glad we were criticised on how we were scrumming for PoC. There's no denying the amount of work we got done for it, and in a lot of ways I wouldn't change a thing about how we did it, but it wouldn't have went as well for Alpha taking such an unstructured approach. I'm also glad we swapped to hours for estimations because they just make way more sense to us as a team. Points felt a lot like guess work often due to the uncertainty of some tasks in terms of knowing in advance how much "effort" it would take, where as hours is something we can all tangibly estimate in terms of how much work can be done in a certain amount of time.