How did working with scrum affect our development?
Well, it’s been neat. Every Monday we meet at roughly 10:00, unless there is a class, for our sprint planning. Everyone participates in picking out tasks and filling in the form. By the end of the meeting we have a clear understanding about what’s happening and who’s doing what. The meeting is also a perfect opportunity for us to communicate to each other about shortcomings and if we need help with anything. By now, we know each other’s skills and can divide the work into something that will be doable in a single sprint, which I find very valuable myself.
However, there is something that I’ll have to admit have been missing, and it’s mostly my fault. Our group have not looked at many user stories, almost none. They have not felt entirely relevant, at least not during the first half of the project. At first, I felt that we didn’t need them. We already had the concept document to fall back on. Early on, this worked. User stories weren’t needed, or so I felt. I do, however, see now why they are important, and how they tie into working through scrum.
User stories allow the designer to see what’s most important at the very moment. When building software, one should always have a working product at the base of it. So, do not start with the wheels, then the engine and then the rest of the car. Start with a skateboard, then a bike and at the end, the car. The product should be less and less bare-bones by the end of every sprint. This way, the designer can see clearly what works and what doesn’t without working too long on something. The user stories help us understand this, and it’s a shame that it has taken me this long to get it.
Our project has mainly been us winging it. We kind of guess what’s most important every week and roll with it. It has worked out for us, but mainly due to our team being clever and experienced, but our game could be so much better. Our product has not gone from skateboard to car.
By now, we’re hitting Beta, so our game will not be seeing any great changes, so introducing user stories now seem like a waste. By now it’s better for me to fine-tune the game into the best version of itself, but I have learned from my mistake and won’t be making it again. Next project’s sprint planning sessions will be very different.
Teo's game design blog. 
Hi Teodor!
Thank you for an interesting post.
As a game designer to be, I especially enjoyed reading your reasoning about user stories and how you have changed your way of thinking about them. You write in a way that makes it easy to follow both what you are writing about and why.
In your post, you describe that you, in the beginning, could not really see the point of using user stories for the sprint planning since you had the concept document to fall back on. Then you describe how you as time went by, realized that there was a power in the user stories that you had not used and that you have learned a lot from this, something that you will benefit from in your next project.
Since I also have “design” as my minor, I have spent a lot of time thinking about this user story thing. The interesting thing – for me now when I read your post – is that I kind of have had the opposite experience in this project. I started right away with introducing the team in user stories and told them this is the way we are going to work. It has worked well I think and the team says that they have appreciated the user stories. Now when more than half the time for the project has passed, I have started to feel it is harder to prepare the user stories for the sprint planning than it was in the beginning. I actually was thinking about not use them anymore but find another way of creating and prioritizing the tasks for the team. Now, after reading your reasoning, I think I will change my mind again and try to go back to the user stories for the rest of the project as well. It is never too late to change your mind, thank you for that!
I have no suggestions for improvement regarding this blog post.
/Anna Malkan Nelson, Kraken
GillaGilla