The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
||My name is Samuel and I'm a nicotine addict. I use a form of tobacco called snus. It is very addictive and I don't fare well if I'm without it for an extended period of time.
You can purchase it in any store in Sweden, but it is pretty hard to find in other countries (actually illegal). This creates a bit of a problem for me as I'm travelling quite a lot. I need to remember to bring a sufficient amount for my trips, or else I will not function.
Typically it's a pretty trivial problem to decide on how much to bring for a trip, my consumption rate is a well known factor; I consume about one box a day.
In August I went on a 12 day trip to Japan, for some reason I only brought 11 boxes of snus. With about 6 days left of the trip I realized my predicament. Now I had two choices, either go on as usual and take a big hit the last day or distribute the pain by slowing down my consumption rate. I chose the latter and was able to get home to Sweden with one last snus to enjoy in the cab ride home.
When I was standing there with my 5 cans of snus I realized that this is actually the same thing that is happening in a well run sprint. In good time you can realize that your current work rate is not sufficient to finish the work you have committed to. Though, with a slight twist, I would prefer to have snus left at the end of my time box whereas a sprint team would prefer to be out of work before the time is up.
Two questions you can ask yourself in before and during a sprint are:
- Do you know your quantity of work?
- Do you know your consumption rate?
The better knowledge you have about this, the earlier you can realize you will not be able to complete the sprint.
Most game teams I've encountered seems to enjoy a good party, at quite frequent internval. Since sprints tend to end on fridays it should be quite a common conflict between finalizing everything and the party. Cancelling the party to finalize the goals takes a ballsy producer, and they will be respected for it unless it happens every sprint.
With an early realization of problems the team can distribute the pain better. Actually it might not even require pain at all, just a tad bit of extra focus.
But why bother? If we miss a goal here or there, what's the big deal?
I like to think of goals as something very valuable. Not bothering about finishing a goal will lower the value of all the remaining the goals and also reduce the positive feeling of completing something, as it's not valued. Production starts to decay when this is done too fequently, people will stop caring.
It's quite common to just move along unfinished work to the next sprint and finalize it there. In the process we are also taking on some new work and some of that work might not be finished, so really polishing the last sprints goals might not seem as important.
Not properly finishing things means that we are pushing a pile of crap in front of us. At some point we will have to dig into that.
This topic has been debated over and over again in the games industry. It might be that we are better at managing this today than we were ten years ago. But, saying that we're done would be exaggerating.
Continuously missing short term goals and leaving unfinished work behind us will hit us at some point. Better prediction of short term goals can help us keep the game in better shape and hopefully make the end phase more endurable.
Don't apply this thinking to the backlog
If breaking down work for the coming sprint makes sense, why not just go on and break down the whole project into small tasks? It is easy to make a induction chain, saying that if it holds for two weeks it should be valid for 4 weeks as well and so on. Fortunately (or unfortunately depending on how you see it) this is not the case. The more uncertainty you have in the system, and games tends to contain an abundance of that, the less accurate your predictions will be. This is one of the reasons sprints should be short, the other being that completing a sprint should involve a beer or two.
For more thinking around this topic I'll push for another post:
The producer role
Being producer is not an easy role, if you doing a good job helping the team to avoid problems it's not going to be noticed, but if you fail to do so it will most definitely.
Going back to my snus example, the producer should help the team to keep an eye on their consumption rate and their workload. The input provided by the team members will allow the producer to give back their gift, an improved quality of life.