Sprint Planning

Architecture and Best Practices

• Programmers have opinions about everything. This is an experienced programmer’s detailed guide to using variables well, with numerous examples. “Software is written for people to understand.”
• A beginner programmer asks for help forming good coding habits in Unity. Experts answer. “What are some good scripting habits to form? For example, is it a good idea to expose variables in your code, such as the speed of your car or the damage done by an attack?”
• A short guide to asking code questions that get answered, including a specific example.
  • An even shorter guide, by one of the most prolific question-answerers online.
• A list of good practices for Unity projects, with explanations. Many are useful for beginners.
• A frequently updated list of good practices for Unity projects. Most tips are at the intermediate to advanced level, but beginners can learn from glancing over it.
• An overview of commonly used design patterns in game programming. Intermediate to advanced level. Examples are in C++ but are well explained.
• Some of the content from the previous site, rewritten in C#.
• A general guide (that is, not focused on games) to C# implementations of design patterns. Intermediate to advanced level.
• A short, specific example of a design pattern applied to Pac-Man.

It’s time to make your next sprint plan!You’ve got two weeks of development left before the end of the course – you're getting closer to actually publishing your game and it's likely time to make some cuts so you end up with a finished game.We’re going to ask you to playtest this week's build with real players at the beginning of the next module. That doesn’t mean it needs to be finished – in fact, the opposite is true – but you will want to have something that’s ready to play.To get ready, look at your game as a player. Go ahead and show it to a friend, post it in the Connect Group or post this week's build somewhere and ask for feedback in the forums.

• What parts are working (understandable and fun)?
• What parts feel broken or unfinished?
• If something is broken or unfinished, do you really need it, or can you use that time better by improving the core of the experience?

The instructions are the same as last week, but for your reference, they're provided below. When you’re finished you’ll turn in some form of your sprint plan.

Weekly Sprint Review and Plan

These instructions describe the exact process that professional teams of all sizes use to manage the work of game development. It has several steps, and it looks long because each step is explained, but it should only take 5-10 minutes to do for a small project.

You’ll use the same system you used when you made your backlog, whether that’s a spreadsheet, a to-do manager like Trello, or a dedicated system like JIRA. When you’re finished you’ll submit in some form of your sprint plan as screenshots or a video capture.

Part 1: Review

Taking a couple of minutes to learn from your experience each week will make you a better developer.

1. Get better at estimating. Look at your current sprint plan – that’s the to-do list you made last week. Observe what you did and didn’t get done. Look at the estimates of effort you made for each item. Were you able to make an accurate guess about how long the task took? If not, what was it that made the work take longer? Just stopping to think about it will make you better at estimating your work in the future.
2. Recognize your hard work. You might be disappointed in your progress this week – that’s actually pretty normal. But take a moment and pat yourself on the back for what you did get done. You’ve climbed a little further toward being a game maker, and everything you did this week will be easier from now on.
3. Reset. Take everything you didn’t finish and put it back in your backlog. That might mean copying and pasting in a spreadsheet or physically moving Post-It notes, depending on your system.

Part 2: Plan

1. Leave the room. It’s a good idea to physically stand up and leave the room, but failing that, at least close your eyes. Imagine your game in its final form. Think about where your game is currently, that is, what’s already visible in the build. Then open your eyes and return to your work station.
2. Update your backlog. Look at the stories in your backlog. Based on your vision of the final game, do you notice anything missing? Is anything unnecessary or not as important as you thought? Are there any stories that could be combined or split into smaller parts? Once you’ve updated the list of stories, look at each story in turn. Ignore its current priority and whether you’ve already done work on it. How important is it, right now, to finishing your game? Update its priority accordingly.
3. Look at your availability. No week is the same. Do you have doctor appointments, lunch dates, algebra tests, or meetings with your agent? Think about each day in turn and write down how many hours you will have to give to your game this week. If the answer is zero, write zero. If you plan to work all seven days, consider taking a day off in the middle so you don’t burn out. 4.

Choose your tasks.

Now that you’ve identified the most important remaining work and the time you have to spend on it, choose stories from your backlog that you will work on this week. As you copy them into this week’s plan, go ahead and give some thought to how you will implement them. Does your estimate of effort (1, 2, 4 or 8 hours) seem about right? When you’re done, make sure your total workload matches up with your actual availability this week.