| Return to index |
In the last post we discussed game design documents for small projects and briefly discussed the importance of the document. In this post I think it would be wise to have a look at scrum and sprint planning as this was another area that we were lacking on that project.
At the start of a new project, I find it can be quite daunting to plan all the individual tasks that are required to achieve a minimal viable product (MVP). Often, I just get excited about a new project and jump straight into the deep end to make things happen and in this case, the others followed suite. This is probably another reason why we lost sight of our goals in the project, we had no defined to-do list or scrum board. It came as a bit of a surprise when we realised that we were missing a couple of aspects from the project and as a result we did make a scrum board, but it was too little too late. This could of be avoided if we had planned our sprint at the start of the project and define a scrum board to our track progress.
So, what is sprint planning and how could we have utilized it to improve our process?
Sprint planning occurs at the start of a sprint usually lasting 2 weeks [1][2] (although in our case we had 1 week). The purpose of the event is to define what can be achieved within the time frame and who will accomplish the individual tasks. Usually, a sprint planning session is attended by the product owner (PO), the scum master and remaining team. Furthermore, sprint planning should be timeboxed to no longer than 2 hours for a 2-week sprint. However, in our case we were only doing a single week sprint so 1 hour should be sufficient and with the project being so short we don’t have POs.
At the beginning of sprint planning it is necessary to define a sprint goal, so everyone knows what we are working towards, then several tasks need to be assigned to achieve the overall objective. This process should be broken down into several steps to achieve the desired outcome.
[fig. 1. The Scrum Framework Poster]
Often, the hardest part and arguably the most important part of planning is estimating how long it will take to achieve the task, as this can be the different between a successful or unsuccessful sprint. Furthermore, it can indicator if the sprit is realistically achievable or not with the team’s current skill set. Basically, it’s a method of forecasting with the information that is currently available. Often techniques such as t-shirt sizing [3] and planning poker [4] (also known as scrum poker or story points) are used. In T-shirt sizing, each member of the team will place down a t-shirt size which will then give a rough idea of how long the task will take based on the team’s skill set. Moreover, Any T-shirt size that goes above large must be broken down into smaller user stories. In a blog on Medium.com [3] Janaka Fernando give his gives his estimate range for each T-shirt size.
XSmall = 1–2 hours
Small = 3–6 hours
Medium = 7–21 hours (1–3 days)
Large = 28–56 hours (4–8 days)
[Janaka Fernando, T-shirt estimate range for User stories]
Another important aspect of sprint planning is coming up with users’ stories and I fell that they are often overlooked among university teams. Personality as a programmer I’m not a fan of user stories as there is often overlap in coding tasks, however, I do believe there is merit in the approach. It’s all well and good having task such as Implement Move Functionality or Create Run Animation but it hard to know what “complete” really means as it’s very vague. User stories overcome this describing the work from the customers or end users’ point of view. A typical user story consists of As a <type of user>, I want <a goal> so that <a reason> [5]. So, the above tasks would become As a player, I can move the character to explore the world or As a player, I want to see the running animation to empathise that I am moving faster. By defining user stories in this manner, it becomes clear and measurable when the task is complete. As an example, we know As a player, I can move the character to explore the world is complete when the player can move their character around the world. Furthermore, it is beneficial to break down user stories into the individual tasks that contribute to the outcome such as a to-do list.
In the short 1-week project that I was working, we failed to do any form of sprint planning. However, we did discuss what needed to be done and tock notes, but we didn’t form a sold plan containing all the tasks that where requires. Furthermore, we didn’t do any form forecasting how long a task would take nor did we have a measurable way of knowing if a task was completed or not. It was a bit of a surprise when we realised, we had missed a few points on the brief which become a bit of a rush at the end to get it implemented and therefor complete. I found it was frustrating not knowing where everyone was in the project and it led to sub-optimal and rushed product. In the future if no one is taking charge of the project planning I will be more assertive and push for a scrum board from the start. Since it allows us to keep track of the project and therefor the product should benefit from the process.
[1] D. West, “Sprint planning,” [Online]. Available: https://www.atlassian.com/agile/scrum/sprint-planning, [Accessed 13 October 2021].
[2] K. Schwaber and J. Sutherland, “The scrum guide,” Scrum Alliance, vol. 21, no. 19,p. 1, 2011.
[3] J. Fernando, “How I use T-Shirt sizing as a Product Owner to estimate delivery,” [Online]. Available: https://medium.com/serious-scrum/how-i-use-t-shirt-sizing-as-a-product-owner-to-estimate-delivery-4b24634d22a6, [Accessed 13 October 2021].
[4] Visual Paradigm, “What is Planning Pocker in Agile,” [Online]. Available: https://www.visual-paradigm.com/scrum/what-is-agile-planning-poker/, [Accessed 13 October 2021].
[5] Mountain Goat Software, “User Stories,” [Online]. Available: https://www.mountaingoatsoftware.com/agile/user-stories, [Accessed 13 October 2021].
| Return to index |
Please refer to the Licences and Sources document for content used from external sources along with usage and licence infomation