Today i want to talk about the backlog and parallel projects.
It is common to encounter problems while working with two projects at once. At the moment we tend to structure our work so that it clashes with our ordinary school work. Handling scheduling gets difficult and our insight into our teammates situations regarding time spent on lectures, homework and other school-related activities tend to be vague at best. Many blame the schools scheduling and lack of communication for the problems. While I believe that the scheduling causes a lot of trouble I also think that there is a lesson to be learned here. When teams work with parallel projects the work in these projects tend to be prone to have problems with teammates prioritizing one project over another. In our case we have one project were we are supposed to create a space shooter while at the same time handle our ordinary school work. These are usually handled as two different projects. When planning time in these two projects we tend to forget to check how much time our team have to spend on school. Some weeks are more intense than others and this is often not taken into consideration when planning.
I believe that this is a mistake. There is a big risk of over scoping, create stress and get in to situations were teammates can’t get a good idea of how much work they can commit to in the upcoming sprint. The different minors involved in the projects all have different school schedules and different homework. If this is not taken in to consideration and visualized it is hard to get a grip of the team member’s respective workload.
One way to lessen this problem is to have your team pull work items from the backlog. This allows team members to commit to the amount of work they believe to be realistic for the current sprint instead of forcing them to do more work than they are committed to. I also believe that it is important to visualize the total amount of work hours of each team member in their parallel projects. Instead of dividing school and the project you can make a combined backlog of both projects in one overarching backlog. By doing this it becomes easier to plan school and project work in one and the same sprint plan.
Current planning method
School 20 Hours (Not visible while planning)
Project 20 Hours
New planning method
School & project 40 hours
While it can be helpful to put school activities in to the backlog I believe that the main purpose of this should be to visualize the workload, not control the school work items. How team members handle school is their business alone. But don’t let it influence the project to much. All team members are still obligated to commit to the project. The important part is to help each team member visualize the current workload and make it possible to consider the work load from parallel projects while planning and committing to work items. If you don’t visualize your school work you skip out on visualizing 50% of the total amount of time spent working.
Team member X need to study math for 5 hours.
Fix an assignment that takes up 8 hours
Take care of upgrading a failed assignment that takes 2 hours
and go to lectures that take 10 hours.
Suddenly you see that team member X has a workload of 25 hours. These non-visualized 50% of your work time is already over 20 hours. If you had visualized this it would have been easier planning around it knowing that you might need to put down 5 hours extra in school this sprint. While this might not be an issue if it happens now and then it adds up over time if X continues to have a heavy work load. This often creates stress, waste and overworked team members. In this particular case you would have had 15 hours left to fill a 40 hour week. This makes it easier for team member X to see the situation for what it is and commit to the correct amount of work that X feels is realistic. At the weary least this planning method should help visualize the workload of the team members and thereby help team members understand each other. This can lessen tensions in teams that feel an imbalance in the workload. The team is also able to make better estimate what can be done in the project.
Planing in one backlog might also contribute to help the team members optimize how they structure their work. Some of the things you are working on regarding school might actually be something that another team member might be able to help you with. The team might also be able to structure time so that they can solve both the project and school assignments more efficiently by working and planning together. This is done by optimizing the amount of use they get from working together. They might schedule working with the project for 3 hours, go on lunch for one hour and end by helping each other with math for one hour before going to class.
I believe that this also makes it easier for the whole team to balance (in the case of our project) the amount of art, code and sound that interact with each other. If an artist commits 9 hours to school work and 31 to the project while a programmer plans to work 17 hours on the project within the same sprint you can see that there might be too little code to make use of the art. This way you can plan around this to make the best of the situation. This lessens the amount of waste by avoiding to many asset imbalances.
While there are many good things with using the backlog in this way I also believe that it is important to not go overboard. Don’t let the documentation take up to much time. I believe that the most value you get from planning in this way in our particular situation comes from visualizing what needs to be done in and outside the project. It is also not supposed to force anything on the separate project. It is meant to help the team balance two parallel projects and make it possible to make better estimations and sprint plan commitments.
There are thousands of ideas on how to visualize and communicate.
Find which one works best for your team.