Scrum is introduced as a product development framework by Ken Schwaber and Jeff Sutherland at Object Oriented Programming, Systems, Languages and Applications Conference, 1995. Prior to its presentation, proposed framework has been used successfully by presenters and their colleagues at major companies to name few as; Individual Inc, Fidelity Investments, IDX.
Scrum is a lightweight and easy to understand framework which aims to manage complex and adaptive product development problems to be handled productively and creatively with highest business value possible. Scrum framework consists of scrum team (which consists of product owner, scrum master and development team), scrum events (which consists of sprint planing, daily scrums, sprint review and sprint retrospective), scrum artifacts (which consists of product and sprint backlog with increments, sprint goal) and rules that binds all these together to define their relationship and interaction.
Basic asset of scrum is experimental knowledge. Following the way of empirics, scrum followers believe that usable and appliable knowledge comes only from experience, and what should be done to leash complex problems is, to use an iterative incremental approach based on knowledge of experience to control the essential risk. In order to encapsulate and digest this knowledge, scrum team should; be as transparent as possible, be inspecting for possible deviations and make adaptation in order to take necessary action to correct the path in case deviation is seen.
The first rule for transparency is agreement on used definitions and, one of the most important definition for scrum team is the definition of done. The actual detail is left for organization but probably definition of done should include unconfusing and teamwise accepted statements on functionality, test, documentation and integration. Work for a particular task is said to be finished only if it obeys definition of done. Development is performed with cross functional self contained teams in the sense that team members are capable of handling all the work without needing an external hand, besides, all of the members are responsible for the finished work. In order to produce incremental value at each iteration, everything (definitions, requirements, tasks, problems and proposed solutions, finished work in the sense of done) should be homogeneous and transparent.
This transparency is mostly handled in time limited daily meetings called daily scrum. In this short interval, team finds opportunity to synchronize and homogenize the experience of previous day. Each member clearly states what is done from last meeting, and what will be done due next meeting. Any experienced problems are discussed with solution alternatives, therefore scrum events also provides a possible place for inspecting any divergence and making adaptations to correct the path back to target.
Scrum events are coordinated and organized by scrum master. Scrum master is in fact a scrum team member not hierarchically superior than rest of the team, but master in the sense that he makes the process coherent smooth and well organized. It is scrum master’s responsibility to make tasks transparently and well understood by the whole team. These tasks are in fact called sprint backlog, the tasks that are planned to be done at the end of some specified period called sprint.
In scrum, the problems are attacked incrementally in regular time periods called sprint which usually lasts about one month. Tasks to be completed is determined by product owner, who is responsible for maximizing business value. He tries to accomplish this task by controlling the tasks in product backlog, somewhat list of “things to be done”. He should make these tasks clear to development team, and reorder the tasks due to business needs. His decisions are final from development team perspective. Product owner may represent a goup of people but he should be a single person to form single point of contact in order to avoid any confusion.
At start of sprint, in sprint planning, some of tasks in product backlog is chosen to form goal of the sprint, sprint goal, and tasks that will be handled in the sprint now becomes sprint backlog. Then, with coordination of scrum master, and with daily scrum meetings, development team take tasks from sprint backlog and transform these to incremental work, overall forming a “done” product at the end of sprint cycle. This done product should be in deployable quality. Development team size should be enough for preparing a significant amount “done” work at the end of the sprint, and should not be too large to cause communication and synchronization overhead. Depending of the project type, teams of 3 to 9 developers seems to be appropriate.
At the end of sprint, a sprint review is performed to inspect increment and sprint goal Deployable done product is now presented to stakeholders. Evaluation of sprint achievements is done, and reevaluation and re prioritization of remaining product backlog is performed. This is done to make necessary modifications in light of gained experimental knowledge and changing market needs. Sprint review is another place for This review will also help subsequent sprint planning.
Sprint retrospective is done by scrum team internally and somewhat informally, in order to see, what went good and bad during last sprint. Opportunities for improvement is investigated and team evaluate each other in terms of their overall communication, collaboration, and performance.