The Backlog

As we’ve gone along building this game, we’ve noticed a lot of things that we might want to do. We’ve made some little lists, like the one in the previous chapter, that looked like this:

  • Button placement
  • Max velocity
  • Turn rate
  • Fire missiles
  • Collisions
  • Bigger better ships
  • and plenty more …

Scrum says that your Product should have a “Backlog”, a list of all the things that need to be done. The Backlog is dynamic, but it is the master list from which you (your Product Owner) select what’s to be done next.

We’re being much more casual than that, for a few reasons:

First, this book is about how one explores a language, a system, and the notion of some product, making progress in learning and in product as one goes. It’s not a book about Scrum: it’s a book to demonstrate how we think about these things, to show what we encounter as we do it, and – I hope – to give you useful ideas about how you do your work. Not that I’m saying you should work like I do. On the contrary, if all I can do is serve as a bad example, I’ll still have contributed. Nonetheless, I do work this way on purpose, having tried a lot of ways of doing things, so I like to think there’s value in here somewhere.

Second, there are just a few of us: sometimes me, sometimes Tozier and me, sometimes Chet and Tozier and me. So we don’t need a lot of formality even if we wanted it and we surely do not want it.

Third, since we are building and running the product all the time, we are confident that anything it needs will make itself quite visible to us. The buttons not working, from the end of the previous chapter, are a perfect example: we thought buttons were working fine. Reality showed us otherwise. We shifted priorities and dealt with the issue.

Fourth, we are scribbling down what we plan to do, right here in the text. So yesterday as we worked, we mentioned the list above a few times, as we decided what to do next. So we do have a bit of a backlog.

Nonetheless, it may be useful to make a list of things I believe the game may want to do, from time to time. So here, without benefit of a pair, is a list:

  • Ability for ships to fire at each other. I think the game will be boring if all you can do is fly about.
  • Ships can explode when hit by missiles. See above.
  • Ships can explode when they run into each other.
  • The original game had a sun. We should have a sun.
  • The sun had gravity. We should have gravity.
  • Ship missiles should perhaps be affected by gravity. Try it.
  • The original game had a star field. So should we.
  • The original star field was accurate. Do this if we can get the data?
  • Ships need to be more easily distinguished. Color?
  • Buttons are poorly arranged for hands. Adjust them.
  • Is the flight area just the middle, or can you fly under the buttons?
  • Should a ship die upon being hit once, or should it take a number of hits to kill it?
  • Should there be a cumulative score of games? Best three out of five?
  • Player high scores vs other players?
  • Options via parameter switches? Which ones?

You can see here why one might recommend against having a Backlog. It would be easy to make this list so long that you’d never get done. But the fact is, the game will be interesting and somewhat fun as soon as you can shoot down the other guy. Playing it will tell us what it needs, far better than speculation.

Still, we have a list now, and we’ll look at it from time to time. Not as fun as programming but worth thinking about for a few minutes.

Next time, I think: missiles.