The Scrum Process is a highly iterative incremental process for developing software packages. But it could also be applied to filmmaking. It is a version of the agile “use-case” process which creates small workable portions of the big project per work-session.
Overview of the Scrum Process:
First, the requirements of the overall software package are determined and organized into a document called the Product Backlog. These requirements are based on “user stories.” These user stories are categorized and generally broken down into tasks. The major tasks are broken down into smaller tasks that can be accomplished in segments called “Sprints.” Each sprint has a “Sprint Backlog” that explains what is to be accomplished by said sprint. At the end of each sprint the goal is a usable functioning product, which contains the features described in the sprint backlog. Simply stated, every sprint adds new features to a work-in-progress, however, at the end of each sprint a potentially deliverable featured software package is demonstrated.
As mentioned, each sprint has a sprint backlog. This document outlines the requirements of the current sprint and these requirements are frozen until the end of the sprint. Basically, no changes can be made to the plan during a sprint. The team works through each sprint on only the features required. Every day the team has Daily Scrum Meetings in which they explain what each member has accomplished and what they plan to accomplish before the next meeting. Meetings are typically short and are designed to keep the team on task. There is also a Scrums of Scrums meeting where groups of teams meet to discuss over-lapping features that each team is working on. These meetings are also typically very short and designed to prevent overlapping and again, to keep teams on task.
At the end of each sprint, there is a sprint review meeting. These meetings are typically limited to four hours and describe what was completed during the sprint. These meetings include stakeholders, managers, the product owner, the scrum master, and the team. The team provides a demonstration of the features created during that sprint and possibly how these features intact and work with features created in previous sprints.
After the sprint review meeting, there is a sprint planning meeting to get ready for the next sprint. These meeting come up with the requirements to be frozen in the sprint backlog. These meetings assign tasks to each of the teams/members. Also, the amount of time designated for the sprint is determined. These meetings typically involve the team, the scrum master, and the product owner.
The scrum process designates specific roles as follows:
The product owner is in charge of the Product Backlog and making sure the requirements of the stakeholders are met by the product. The product owner manages the “user stories” that define the requirements for the project. These stories go in the product backlog. These user stories are typically short plain English sentences or statements explaining the requirements of the software being created. They usually come from the project owner, stakeholders, or anticipated users of the software.
The Scrum Master or Project Manager is in charge of managing the team(s). His or her role is to catch problems before they start and make sure any issues are resolved quickly. It is important that the scrum master is not considered a team leader, because the team is self-managed, however, the scrum master should act as a barrier between the team and any outside sources that may slow down the team or hinder their performance. The scrum master is also there to be sure the scrum process is being followed properly.
The Team is the last of the actual working project roles, but obviously the most important. The team carries out the scrum process and is solely responsible for the delivery of the project. The team is generally composed of five to nine members.
Other project roles include; stakeholders, which are the typically the funding for the project, and those who are most affected financially by the outcome, and managers who will set up the situation for using the software.
How Scrum Can Work for Films:
Now that we have a basic understanding of the scrum process, we can figure out how this will work for the creation of a film. Films typically are large-scale projects, which make them a good candidate for the scrum process. Films also can be thought of as a collection of results from several independent processes (features like script writing, budgeting, production, post, etc.) which makes filmmaking a good candidate for the scrum process.
Because of the size and the amount of features required of a film, breaking the project into sprints should not be an issue. Developing small working “deliverable” projects for every sprint will be a challenge - but one that can be met.
The roles need to be determined. Someone needs to be the stakeholder. This party would serve a key role in creating “user stories”.
Creating small “deliverable” pieces during sprints should keep motivation up.
Example of a Successful Scrum:
The following is an excerpt from an article from The Scrum Alliance called “How Scrum Helped Our Team” by Samir Bellouti.
After some debate, the scrum process was used to recreate an airline booking website with a lot of detailed requirements and it had to be connected with a large-scale back end system. The management did not want to use the Scrum process because it did not give time or expense estimates on a large scale. Each Sprint would have its own estimates, but the whole project was somewhat in the dark. The author explained that their current method (the waterfall model) only gave idealistic information. Simply stated, they had estimates, but these estimates would most likely not be met, or the software would be delivered with less than the desired requirements.
So finally the management agreed and the Scrum Process began. Through the early sprints the team gained confidence quickly. They were able to come up with deliverables about every four weeks. The management began to have faith in the team, and only monitored the team's progress at the end of each sprint, as it should be. At each Sprint meeting there would be new user stories, and the requirements of the next sprint would be frozen.
The team became more accountable for each other. In general, when one team member finished his or her tasks for the day, he or she jumped over to help another team member with tasks. Without an actual “Leader” during the sprint, the team is accountable for the deliverables of the sprint. Because the tasks are small, this process worked out very well for this team.
Because the sprints provided workable projects, different departments within the airline booking company could “play” with the tools that had been created.
Departments such as marketing, and management were able to point out potential flaws and report them back to the teams to work on during their next sprint. Eventually, it was evident that the project would not be completed by the anticipated time, however, the management of this company was pleased that they had some notice. They had said with the waterfall model, sometimes the delivery date would come and go before they realized it had passed. The Scrum Process was able to predict the late delivery in time to plan for it.
Once the team figured out what they had accomplished, they were able to predict what they could accomplish and give an accurate time line. The project backlog became very useful for this and other tasks, such as changing requirements, and figuring out bugs.
The team dedicated their last sprint to bug testing. They had expected to put some major hours in, but such was not the case. Because the company had access to the builds before the final project, bugs had been fixed as the project went along. This prevented the project from having many bugs by the end of the project's time line.
The project launched with no major issues. Transactions processed on the first day.
Nick Martinolich is a graduate of UCF, currently at work in film production in Los Angeles.