Scrum (Agile Software Development)
Scrum was intended to be for management of software development projects. It is a holistic approach which increases speed and flexibility in commercial new product development. The whole process is performed by one cross-functional team across the different phases (the rugby method). Depending on the situation scrum can be adopted or changed to fit specific needs.
ScrumMaster maintains the processes and works similar to a project manager. His primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended.
Product Owners represent the stakeholders and the Team which includes the developers (In my experience they are the producer and the design director). It is imperative that the Product Owners work closely with the publisher or investors. Most game developers work for hire and they need to make sure that the client gets exactly what he expected. The expectations and needs must be explained to the scrum teams.
The Team has the responsibility to deliver the product. A small team of 5-9 people with cross-functional skills to do the actual work (designer, artist, programmer, etc.).
Pigs are the ones committed to the project and the Scrum process; they are the ones with "their bacon on the
Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.
The software is being built for consumers.
People that will set up the environment for the product development.
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potential shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a ranked set of high-level requirements of work to be done. What backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint.
During sprint session no one is able to change the sprint backlog, which means that the requirements are frozen for sprint. One of Scrum's biggest advantage is that it is very easy to learn.
Each day during the sprint, a project status meeting is arranged. This is called a scrum. Scrum has specific guidelines:
During the meeting, each team member answers three questions:
After each sprint a sprint retrospective is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to improve the scrum process. This meeting is time-boxed at four hours.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach ï¿½ accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
Product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to measure the timeline and, to a limited extent, priority (e.g. if "add spell-check" feature is estimated at 3 days vs 3 months, that may affect the Product Owner's desire).
The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned; rather tasks are signed-up for by the team members as they like.
Burn Down Chart
The Burn down chart is a publicly displayed chart showing the number of tasks remaining for the current sprint. It should not be confused with an earned value chart. A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule. The chart is maintained by the Scrum Master.