Agile software development offers a fantastic opportunity to integrate user insight into the game development process, leading to better games. In this post, I’ll cover the main methods that can be used to integrate user insight into agile games development, and why this is important.
Agile is a software development philosophy which encompasses a number of ideals, most interestingly the idea of delivering working software over excessive documentation and planning. Distilled to it’s core essence, it divides project development into short (bi-weekly) ‘sprints’, where an agreed amount of prioritised software is constructed, tested and delivered.
Because of Agile’s emphasis on delivering working software as soon as possible, it gives plenty of opportunities to integrate user insight into the process, and user insight in turn gives a wide range of benefits to software development. In games, it can mean the difference between addictive game-play, or a dull experience.
So, how should user insight be integrated in order to create a successful game?
1. Gather user insight before you start.
Before the project begins, it is typical to have a ‘sprint zero’, to allow necessary preparation/evaluation of the problem to be performed. This is an ideal time to start on user research, since the cost of integrating any findings would be minimal
A variety of techniques could be used to understand users before production has begun. Paper prototypes, or evaluating competitors products will give insight into what aspects of the game would be desirable, and which are unnecessary. Evaluating competitor’s games is practically free, and will prevent you from making the mistakes that they made!
2. Test at each sprint
Agile delivers working software at the end of each sprint. This gives an opportunity not possible in traditional (waterfall) software delivery – to test an element of your final product with real players. Ignoring the programmer-art graphics, or game-stopping bugs, the core game mechanics can be tested, and refined from a very early stage.
A technique often used to achieve this is ‘staggered sprints’. This is the idea of running user testing in parallel with development, testing what was created in the last sprint, and feeding back refinements based on user testing during the next development sprint. This will give the team the ability to integrate the feedback from users consistently, and improve the next iteration. It will also settle arguments about features!
3. Release early and iterate
Starting with the proliferation of ‘patches’ for games, updating games is now easier than ever due to automated updating platforms such as the iOS App-store, or Xbox Live. This means it is now possible to release a game at the earliest possible stage, and then iterate upon it to update it.
This technique has been used to enormous success with facebook games such as CityVille. By releasing a game early, either to beta testers, or the general public, and improving it based on player feedback, it allows you direct insight into what players want, what they don’t want, and prevents you wasting time on unpopular or unnecessary features.
Plus you start getting revenue from a very early stage – just look at Minecraft’s millions!
A key aspect of Agile is the idea of prioritising the workload. Before each sprint, the most important features are decided upon, and only these are worked on. This means that each iteration will produce the ‘best’ version of the game possible at that stage, and any delays/cuts will only affect the least important aspects of the game.
The advantage of integrating user insight into the game development process, as outlined above, is that it can help inform this prioritisation, and ensure that the features being developed are the ones most critical to the players.
By far the most important aspect of developing games with agile is understanding what aspects are going well, and what needs revision. By working in short sprints with user insight as a ‘review process’, it is easy to judge what areas of the game are working, and which are not.
If this is contrasted to a closed development process, where the players do not see the game until it’s complete, it is often not possible to understand how features will be received, or whether the game is ‘fun’ until much too late! And if you do decide to make changes? It’ll be a lot more expensive at the end than if you’d caught it at the end of a two week sprint – this limits the rework you’d have to do.
In summary, developing games with an agile methodology produces better quality products, and at a faster pace. Integrating user insight into games development is not only possible with agile, but brings massive boosts to the quality of the final game.
Great post…good points. One thing I’d like to say is that I don’t advise of calling the “preparation” period “sprint 0”. As you point out “Agile delivers working software at the end of each sprint”. Since a “sprint 0” doesn’t deliver a working game, it’s not a sprint.
This may seem to be a minor point, but it often opens the door to such scrum-but things as a “debug sprint”, “coding sprint”, “integration sprint” and so on. By keeping the definition of sprint as you state it, it’s far more clear to the team about the goal.
Another, small, point is that “sprint” is a Scrum term. So you should say either:
– Agile delivers working software at the end of each iteration.
– Scrum delivers working software at the end of each sprint.
…and why not use “game” instead of “software”? Shouldn’t the entire game be working?
…but that’s from the nitpicking coach side 😉
All really good points, and I’ll have to hold back the urge to revise the original article to fix the things you’ve highlighted.
I’ve only ever worked with Scrum, and so fall into the trap of using it’s terminology interchangably!
Thanks for the feedback!
… easy way to put these points on the table,
Very good!!!, thank you,