Sprint 3 Retrospective
It’s time for another retrospective. I haven’t done one in what seems like weeks, but as anyone who’s been reading this can see, things were pretty disrupted for a while there. In the mean time, I completed a Sprint #2 in there, somewhere/somehow, and never managed to write a retrospective for it. But here’s the third (second?) installment of my sprint retrospectives.
As a reminder, these are the posts where I look back at the last week, and discuss what worked, what didn’t, and what needs to change in the future.
What Worked
I’m actually really proud of what I completed in the last sprint. The game has really come a long way, and I’ve accomplished some of the things that are the hardest parts of the game, from certain points of view. So I like that I was able to get a lot done.
This is complimented by the fact that, you know, I was able to actually spend time working on this game this week.
I also love the fact that I was able to do some form of Sprint Review Meeting, and post a version of my game out there for people to play around with and give some feedback. And in fact, the feedback is already coming in, and it feels good. Even the complaints, which have so far been smooshed between a pile of positive things, and were all done tactfully. The compliments and critiques will be very beneficial. And if you’re reading this, you still have time to take a look and tell me what you think too.
What Didn’t
My scrum system didn’t really work like planned. For the week, I never sat down and said, “This is what I’m going to try to accomplish.” And I never went and marked what was in progress and what was done. It’s interesting to note that this happened on the very week that I feel like I got the most done. I can’t help but wonder if there’s a correlation between the two.
And there’s a dark question lurking in my mind: Is Scrum the problem? It seems like it can’t be. But is there a chance I’m spending too much time on the (actually pretty limited) formalities of Scrum, instead of making headway with my game? But it can’t be, can it? We’ll see what happens this week, I guess. I think the benefits of Scrum come into play long term, not short term.
Second, I feel like I’m doing a lot of spewing stuff onto this blog. To be honest, I’m not so concerned about the amount of time I put into it (it actually happens pretty painlessly and fast, and helps formalize my own thoughts). And I’m not so concerned with the sheer amount of stuff.
If somebody is spewing gold doubloons soaked in rainbow juice at you, you get as big of a bucket as you can find and enjoy the ride. But even if it’s just silver doubloons in orange juice (let alone copper in “yellow juice”) it’s not so interesting to try to dig through the noise to find the signal.
So it’s something for me to think about. Would it be better to have less, higher quality content that what I’ve got now? Pick the best ideas and edit and review a little more?
But that’s all less about my game and game development than it is about this site, which is kind of a meta-layer to the game anyway. So I’m not going to stress about it too much. (Feedback is appreciated though.)
Another game dev specific problem that I’m a little concerned about is the number of unit tests that I have. I don’t believe in writing more unit tests than is necessary, but I can point to at least three places in my code that should have unit tests but don’t. That makes me a little uncomfortable. And speaking frankly (and hoping that it doesn’t come back to bite me some other day) I know this is an area where I could do better on. I don’t write all of the unit tests that I should, because it’s more fun to move on to the next thing. To be clear, I’m probably being pretty harsh on myself here. I’ve been writing unit tests, just not all of the ones that I know I should be writing. (And that’s coming from someone who already doesn’t think you need to unit test everything.)
What’s Going to Change
It’s pretty clear, from what I just wrote, what I need to do differently. Set up my sprint correctly and do unit tests better. I’ve already set up my Sprint #4, so put a check mark there.
Unit tests are going to be a little harder to talk myself into. Here are a few ideas that might help me.
- Perhaps it would be meaningful to go through my user stories and list the unit tests that should be written for each of them in advance. This would give me a reminder of what I need to do for each item that I write code for.
- I need to print out my Definition of Done and hang it on the wall. That’s something I intended to do all along. It lists writing unit tests as a part of what it takes to call something “done”, so it would be a good reminder.
- I already wrote about why you should write unit tests. Perhaps I should write a second post in the upcoming week about what you should unit test. A second installment to that series. Having that topic on my mind will help me stay focused on actually writing these tests. I’m going to go add that to my list of tasks for the upcoming sprint right now.