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.

[09.29.15]

– Adam Moore