Welcome to another episode of our We Are Screwed! production blog. If you missed the introduction, here is episode #0.
Development Update
We work in two week sprints. Typically. Well, wait, there are some public holidays, then there are people on vacation… so the current sprint was only running for 7 work days. Adding bridge days to the team’s schedule isn’t a good idea either, so sometimes sprints are just shorter.
As we are getting closer to alpha, of course we have been bugfixing a lot in this sprint.
Some of those bugs were discovered in the playtesting stream at the end of the previous sprint. It’s actually quite useful to create clips on Twitch as you encounter issues. Thanks to our nice community for helping us out with that!
If you missed the stream, here is a recording:
Play Austria
We exhibited the game at Play Austria in Vienna last week, and needed to decide which build to show there. So we evaluated the build from the previous sprint, and then prioritized issues and bugs to be fixed for the event.
It’s always a good idea to have an older build ready to use as a fallback (and you will have one once you manage to survive at least one event!), but aside from a rare outside screen/possible camera issue, using the latest one went well for us this time. We received a lot of great feedback at the event – thanks to everyone who came by to play We Are Screwed!
Let’s Discuss Discussions!
Imagine you want to implement important feature A in the coming sprint. The team is confident that it can be done within just a couple of hours, and there is enough time left in the schedule. Should you do it? Well, it depends.
- Are all the prerequisites met to go ahead and implement this?
- Is the feature specified well enough, both technically and gameplay-wise?
- Are there any dependencies to be resolved in the same sprint?
What happens a lot, is that when discussing the tasks for the sprint, you are not exactly sure what the game design looks like in detail for a feature. Most of the time, you have a basic idea where you want to go with this, but the details may not have been fleshed out yet.
“Ah, let’s just discuss this when we get there, and it will still get done in this sprint, right?”
No. In almost every instance, there are multiple people involved in this discussion and the decisions to be made. If you have the discussion and the implementation planned for the same sprint, it is very likely that it is not going to be implemented. The reason for this is very simple: Discussions tend to be postponed a lot, because people are busy. They are working hard on the game, fixing bugs, and adding great pieces of art. When asked to start a discussion, the answer is always something like in a couple of hours, tomorrow, or even next week.
What we are trying to do here, is to have discussions scheduled for one sprint, but the implementation of its outcome in the next one. That enables the team to move around the actual date of their discussion meeting to their liking – and it’s not an issue even if it’s right before your TGIF round of beers.
However, there is another important lesson to learn about discussions: You never know how long they will take. It might be the rare case to decide something within five minutes, but in general, you don’t know whether it will take you one hour, two hours, or maybe six. At first, we tried to plan discussions as tickets, and give them our best guesstimate. It just didn’t work. So we changed the workflow here a bit, and while we still have tickets in our system for discussion, there are no time estimations on those tickets. They only act as reminders – and it’s a good thing to be reminded that we need to discuss something like the stage 1 boss, right?
We also don’t log work hours to those discussion tickets, because this would tamper with the burndown chart. The idea is to log discussion hours somewhere else (we do this via Toggl), so that you are able to reevaluate the overall discussion vs. work percentage. Only schedule a certain percentage to development work, and leave enough time for discussions. Taking a look at previous sprints’ actual percentage will help you plan for the next one.
To be continued…
In the meantime, please feel free to reach out via:
It took us 39684 coffees to get this far.
