For this team project the team and I will be using Agile development to help plan out the development of our game. This is to ensure that we are aware of the game’s progress and how close we are to dead lines.
During my lecture we discussed Agile development as a means of planning your product for the user. When doing further research in Agile development, I came a cross User Stories, which are the tasks the each developer will have, however instead of simply writing the task as “Develop player movement” you need to consider four things (Measey et al. 2015):
- Who – the player, client, etc.
- What – they want
- Why – do they want it
- Acceptance criteria – a list of requirements for the feature to ensure the story is done
Both from the lecture and the research has shown that from third year to the present, I have been doing user stories incorrectly and have been simply writing tasks rather that actual user stories. Interestingly enough when I was taught how to use Agile way back in year 1, it was never mentioned that we have to write acceptance criteria. However I believe it is something for me to add when writing user stories as it allows the team to know when the feature is fully complete (Measey et al. 2015).
In addition, reading another book on Agile development by Clinton Keith has made me realise that you want to write User Stories that allow for negotiation between the team members as what you write in the User Story shouldn’t describe the complete process needed to create the feature (Keith 2010). An example of a good user story that can be negatable is show in fig 1.
If I was to write User Stories differently I would need to keep them short so that they are easy to understand and so that other teams members can understand negotiate with me about the feature. It would be a good idea to, consider the term SMART as it contains five good characteristics when writing a task(Wake. 2003). SMART is an acronym for:
- Specific
- Measurable
- Achievable
- Relevant
- Timebound
I would also include an acceptance criteria to ensure that I and the team know what the feature should contain in order to be considered complete.
Conclusion
To improve on my Agile skills I will need to write better user stories, I will begin tomorrow (Wed 6th Oct) as I will need to work on a new feature for the Game. I should spend 2 – 5 minutes writing out who the user it, what they want (the feature), what needs to be in the feature to consider it done and add a time estimate for the development. Once done I should aim to continue this way writing every time I make a user story, likely 5 – 10 user stories each week.
Bibliography
KEITH, Clinton. 2010. Agile Game Development with Scrum. Boston, Mass. ;: Addison-Wesley.
MEASEY, Peter et al. 2015. Agile Foundations: Principles, Practices and Frameworks. Swindon, UNITED KINGDOM: BCS Learning & Development Limited.
WAKE, Bill. 2003. INVEST in Good Stories, and SMART Tasks – XP123.
Figure List
Figure 1: Keith Clint. 2010, pp. 126 – 127. A more negatable user story [Image]
MaxMakesGamesBlog 