|
SCRUM Project Methodology
SCRUM is an IT project management method consistent with agile software development regulations. Its framework structure puts forward a set of principles and practises originating from Lean Thinking. The idea is that it is a simple structure for the solution of complex problems through the creation of software to deadline and in accordance with client expectations, where the implementation is difficult as labour intensive, as it requires a change in thinking. SCRUM is am empirical project management method. It comprises a set of practises and suggestions gathered and recorded for the first time in 1993 by Ken Schwaber, Jeff Sutherland and Mike Belldlem. It is commonly applied together with eXtreme programming.
SCRUM structure comprises:
The project is divided into sprints. A sprint is a fixed time period in which software is created. AT the end of each sprint the client receives a functioning product part. With this he may track the progress and direction of product creation. With this envision approach time wasted on creating a product that is not consistent with the client’s vision is wasted. The facility to track team work progress allows for the speedy implementation of corrections into the project plan (when comparing this time to that found in traditional management methods). Three basic SCRUM roles As presented earlier, SCRUM comprises three basic roles:
Each of these roles has strictly defined tasks. The relationships between these roles may be compared to that of a flock of sheep (team), which is protected by a sheepdog (Scrum master) from the wolf (product owner) while grazing (Sprint). Product Owner It is the product owner who is responsible for the project budget. This may be a person delegated by the project sponsor. He defines project vision and aims, and then presents these to the team. The product owner completes the Product Backlog and defines the order of functionalities to be implemented. He prepares the requirements (not specifications), defines acceptance criteria and defines product value. The product owner is responsible for project business value. The product owner accepts or rejects the results of the team’s work. Scrum Master This person aids the team in overcoming impediments, while simultaneously ensuring maximum team productivity. While the Scrum master is a member of the team, he does not have any executive authority over the team; he is to provoke discussion and help in the search for the best solutions. He does not however, have any authority for decision-making, commercial or technical. As earlier mentioned, he protects the team from negative external factors e.g. changes in requirements during sprints, additional tasks or problems. The Scrum Master is responsible for progress in compliance with SCRUM assumptions, he is the master of ceremony. His role is that of host and mentor. Team The Team is an interdisciplinary, self-organized and self-sufficient project team which manages itself – it makes decisions which lead to the achievement of aims within the sprint. According to accepted principles, the Team should comprise 5-7 persons. The Team members must be able to realize the project, and the Team composition cannot change during the project. Three basic SCRUM ceremonies Planning This ceremony commences the Sprint. During this time the aim to which the Team will work to achieve is defined. This meeting should last no more than 4 hours, during which the Team estimates the size of tasks from backlog and commits to the completion of a particular section of them. The tasks are organised into order of rank – their order will comprise an element of the sprint backlog. The team assesses the tasks, comparing their size, complexity and risk. With time, this approach allows for the definition of velocity- speed at which a functionality can be created, expressed as an abstract figure. Daily Scrum This is a compulsory daily meeting during, lasting approximately 15 minutes, during which team members discuss the following 3 basic questions:
Thanks to these meetings, the team, together with the Scrum master, can track work progress and react quickly to any problems which have arisen. Sprint review The Sprint review is a meeting which closes the sprint. It is divided into two parts. The first of these is the User Demo. The team presents functionalities created during the sprint to the product owner and other interested parties. On the basis of this presentation, the product owner declares whether or not the functionality meets the acceptance criteria which were set by the client prior to commencement of work. The second part of the meeting is retrospective, its basic aim being learning. The Team, together with the SCRUM Master, analyses the progress of the progress of the Sprint and identifies areas where improvement is needed. Together, they define small steps to be implemented in the next sprint with the intention of improving work. Three basic SCRUM artefacts Product Backlog This is a basic project list which belongs to the product owner, comprising a set of functionalities to be implemented by the Team. Any team member can enter tasks/ideas into the register, however it is the product owner who decides on the order in which they are realized. Tasks recorded in the backlog may be divided into two categories:
These tasks are organised in the product backlog by the product owner according to business value, from the most to least desirable. Sprint Backlog After each planning stage a team sprint backlog is created. This is a set of tasks to which the team has committed itself. During the sprint, the team monitors progress at daily meetings. Where a risk of not completing all tasks arises, the number of new functionalities may be reduced in consultation with the product owner, or the sprint may be abnormally terminated. Burndown Chart This is a daily progress chart for a sprint over the sprint’s length. When this chart is well maintained, it can quickly signal impediments arising during the sprint. Agile manifesto Scrum methodology meets the norms and values set by the Agile Manifesto. This is a declaration of common principles for agile management methods. The manifesto content was drawn up in February 2001 by representatives of various agile management methods. The manifesto reads as follows: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Agile Manifesto is a collection of basic principles for working in a team, and indicates the method for cooperation with clients. According to the manifesto principles, the highest priority is to satisfy the customer through early and continuous delivery of valuable software. The manifesto does not negate tools, processes, comprehensive documentation or following plans. These are important aspects. However people, interaction between them and working software etc. are of more importance. Very often, the simplest forms of communication are the most effective. The intention is not to abandon written communication, but often a ten-minute conversation will give the same effect as twenty e-mails. Despite the fact that it is this simple, beauracracy is often stronger. Documentation produced during the project should refer to a working product, providing an instruction manual which is prepared to the extent that the client can understand and use it. Projects often end with 1000 pages of documentation which no one will read. The time spent on writing this could have been better used in the creation of software. The plan set in place before commencing work on a project is rarely so precise and detailed that it does not need to be changed, which is why the elasticity provided by SCRUM allows the team to adjust to changing requirements. Sprint progress A Sprint is a period of time in which new functionalities are developed. The sprint duration is defined by the team, the recommended period being from 14 to 30 days. This period allows on the one hand production of a working system part, and on the other, timely information from the client as to whether the functionality meets his requirements. The following illustration presents sprint progress.
The most important SCRUM feature is that after each sprint the team delivers a ready, working application component which can potentially be implemented. During the sprint the team must focus on user stories committed to during planning. Daily scrums and the burndown chart facilitate progress monitoring during the sprint. As soon as any worrying signs appear the product owner is notified. Should the number of impediments during the sprint potentially prevent the completion of all planned tasks, the client must be made aware earlier of the fact. In consultation with the product owner, the team removes lowest priority tasks from user stories so that the sprint may be successfully completed. A sprint is considered successfully completed where all tasks declared by the team have not only been completed, but have also passed tests, and where at least minimal documentation has been provided so that the client may verify work conducted. Each sprint must close with delivery to the client of a ready solution component, which without the aid of a programmer, may be implemented into the production environment. During the sprint all phases commence almost simultaneously. The first of these is the task planning phase. At almost exactly the same time, analysis and design commence. It is significant that not all of these phases must be completed in order to begin coding. Thanks to this approach it is possible to quickly see and test the first new functionalities. Each team should include a tester, who verifies the correctness of tasks presented. Acceptance tests are conducted by the client upon completion of user stories. SCRUM application SCRUM is an effective project management system where the client has an overall outline of the project, but is not able to define precise requirements. This is best illustrated in illustration nr 2. Chaos provides the best picture of the initial stage of the project. Both the client and the team are surrounded by uncertainty of tasks. For this reason, short sprint periods are recommended in the initial project phase, so that the client quickly receives working components, as it is often on the basis of these that further steps are taken.
SCRUM works like a loop, which gives the client the ability to monitor progress after each turn. Based on the program components delivered the client can continually modify the end target. Such information after each iteration allows the correct direction of functionality development to be maintained. The team is sure in its tasks, which is in turn conducive to further work. With the development of the project, the product owner becomes more able to precisely define his requirements and expectations. The elasticity provided by SCRUM allows the team to quickly adjust to changing requirements. As mentioned earlier, such return information is very important particularly at the beginning of a new project, where the client and team are immersed in chaos. Change is a natural factor in the creation of informatics projects. However it is important that these changes not be of a fundamental nature. During the project the client may say that he would like sorting of such a type, and display of a different. He may change the scope of a created product. What he cannot do is change the foundation which was set at the beginning. If he should insist on this, all functionalities delivered in earlier sprints may require adaptation, and in consequence, the project restarts from the beginning before it has been completed. This may give rise to criticism from some sides and the question may be raised as to whether in this case SCRUM is a good solution. The answer is simple – yes, it is still savings in time and money. |
|
|
Case studies |
|
