Managing project scope is crucial to the success of any project, but it's especially crucial to the success of student projects. In this article, I will walk you through the techniques I have used to ensure my projects ship on schedule. Please keep in mind that my approach is designed to address constraints that are unique to student development teams and a purely agile approach may work much better for your team if you are an independent developer or are in the AAA industry. I use a hybrid of waterfall and agile practices that I specifically chose to compensate for the inexperience of students.

Release Planning

I treat each semester of development as a potential final release and each week of class as a sprint. There is no guarantee that a student project will continue into the next semester, especially if the team leads are nearing graduation. With a large project, this means being willing to cut the majority of the features from your initial scope.

The game that you want to make probably won't be the same as the game your team has the resources and experience to make, and your job as a lead is to help the team plan a game they can feasibly release in one semester. You'll need to ensure that the planned release is within the skillset of your team and within the amount of time the team has to work on the release while including high value features and keeping the team focused on the release. This is not an easy balancing act.

The first step in this process is to meet with the product owner and the development team to determine which features the product owner and stakeholders value the most and which of these features the development team is confident they can deliver within their constraints.

Once the scope for the release has been pared down to the most valuable features, it's time to sit down with the development team to decompose all of the features into their component tasks and assigning every task with an hour estimate. Any tasks that are vaguely defined or difficult to decompose are risky and are candidates for being cut from the project. The inability to decompose a large task suggest that the team may not have an accurate understanding of the work that needs to be done to complete the task.

I recommend using Microsoft Project or a free alternative to build out your list of tasks with established dependencies and resources. I'm not going to teach you how to use Microsoft Project - there are already many great tutorials and how-to guides on how to schedule tasks, set up resources, and how to adjust scheduled working times for your project out there. What you'll want to do at this point is ensure that every task in the release has an hour estimate, has its dependencies established, has a named developer assigned to it, and that every developer has a 4 hour work week set up.

It can be tempting to assign a bigger work week to developers, but I would go no larger than a 6 hour work week and I recommend cutting the work week in half for any leads to account for time spent on non-development tasks. Intentionally underestimating your development team's working hours allows you to build in a sandbag that can account for poor time estimates on tasks and can be used as extra polish time at the end of the project.

Once you've completed this, you're going to level your resources and see how long your planned scope will really take to develop. You're almost guaranteed to exceed your deadline. Some minor optimizations can improve the schedule slightly, but you're going to need to cut features. This works best when it's only the leads and the product owner. Developers can get defensive if their favorite feature is on the chopping block and the meeting can get heated if everyone is involved in this decision. Remember that your job is to make sure that the project ships on schedule. You need to be emotionally invested in shipping the product, but not emotionally invested in the product or its features. It's not easy to cut your favorite feature from the game, but you may need to do exactly that if the schedule is slipping and your release date is approaching.

Sprint Planning

Student teams have some pretty tight constraints to work in and managing a student team is a bit more involved than managing a professional team due to these constraints and their relative inexperience. This is why I recommend a much more waterfall approach to task assignment within a release. In agile teams, the team members are expected to self-organize and select their own tasks for a sprint, but this doesn't work as well for students. Sprint planning still happens, but it's your responsibility as the producer to handle the sprint planning for the students.

Once you've finished cutting features and tasks from your release and re-leveling resources, you'll find that every task has a start and end date in Microsoft Project. You're going to use these dates to determine which sprint a task is assigned to and what the deadline for each task is. Future sprints are likely to need to be changed as tasks either fall behind schedule or are completed ahead of schedule, but the best way to handle this on a student team is by tracking the progress with the Gantt chart in Microsoft Project.

This technique has worked very well for me on the student projects I have worked on since I implemented it, but it's by no means a perfect system. If you have any suggestions on how this process can be improved, I'd love to hear about them in the comments.