Scrum methodology report

Transcription

1 Scrum methodology report Author: Tsholofelo Eunice Moitsheki Student number Tsholofelo Moitsheki (463642) Project Source and Documentation: metholodology.docx Course: ELEN Software Technologies and Techniques Revision History Name Date Reason for Changes Version Tsholofelo Vesion1 Abstract This document will detail the scrum methodology and how it should be applied in project management 1

2 Contents Contents Introduction Why Scrum History SCRUM PROCESS Sprint Product Backlog Scope of initial work on the project Spring Backlog Breakdown Sprint Burn down Chart Meetings Sprint Planning Meeting Sprint Review Meeting (Four hour time limit) Sprint Retrospective (Three hour time limit) Conclusion Introduction Scum methodology is an iterative, incremental framework for project management and agile software development. Scrum methodology is a process skeleton containing predefined practice and roles. It is a "lean" approach to software development. It is a simple process that is used to organize teams and work more productively with higher quality output. Using scrum help the team members to choose the amount of work to be done and decide how to best do it, that provide a good productive working environment for the team. Scrum focuses on prioritizing work based on business value, improving the usefulness of what is delivered, and increasing revenue, particularly early revenue. Designed to adapt to changing requirements during the development process at short, regular intervals, Scrum allows teams to prioritize customer requirements and adapt the work product in real time to customer needs. By doing this, Scrum provide what the customer wants at the time of delivery (improving customer satisfaction) while eliminating doing work that is not highly valued by the customer. 2

3 2 Why Scrum A well-functioning Scrum will deliver the highest business value features first and will avoid building features that will never be used by the customer. Since industry data shows that about half of the software features developed are never used, development can be completed in half the time by avoiding waste, or unnecessary work. In most companies, development is slowed down by issues identified as impediments during the daily meetings or planning and review meetings. With Scrum, these impediments are prioritized and systematically removed, further increasing productivity and quality. Well-run Scrums achieve the Toyota effect: four times industry average productivity and twelve times better quality. Teams are allowed to select their own work, and then self-organize through close communication and mutual agreement within the team on how best to accomplish the work. The simple rules of Scrum allow for continual inspection, adaptation, self-organization, and emergence of innovation. This can produce an exciting product for the customer, develop high team spirit and satisfying work, generate high productivity and customer satisfaction, and achieve the market and financial goals of the company. 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 3 History The term Scrum comes from a 1986 study by Takeuchi and Nonaka that was published in the Harvard Business Review. In that study, Takeuchi and Nonaka note that projects using small, cross-functional teams historically produce the best results. They wrote that these high-performing teams were like the Scrum formation in Rugby. When Jeff Sutherland developed the Scrum process at Easel Corporation in 1993, he used their study as the basis for team formation and adopted their analogy as the name of the process as a whole. Ken Schwaber formalized the process for the worldwide software industry in the first published paper on Scrum at OOPSLA

4 3.1 SCRUM PROCESS Figure 1 - scrum process Product owner: Steven Faber Represents the stakeholders and the business. The Product Owner writes customer-centric items (typically user stories), prioritizes them and places them in a product backlog. A Product Owner can be a member of the Scrum Team but cannot be a ScrumMaster Scrum master: Tsholofelo Maintain the SCRUM process. The primary job of the scrum master is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended and enforces the 4

5 rules. A key part of the Scrum Master s role is to protect the team and keep them focused on the tasks in hand. Scrum team: Nipho, Rethabile and Sonja A cross functional group of people who do the actual analysis, design, implementation, and testing. The team has the responsibility to deliver the product Sprint In Scrum the iteration is called sprint. Outcome of Sprint is a potential shippable increment. e.g Working and tested software.. Short sprints provide fast feedback from the customer to development team. The customer has an opportunity to operate the scope of the systems and after he estimates result of the sprint and offers improvements to the created functionality. Such improvements will be added in Product Backlog. Each sprint represents small "waterfall". During the sprint all works on gathering of requirements, design and coding of the product are being processed Product Backlog It is a prioritized list of business requirements and technical requirements available at present. Product owner is responsible for Product Backlog. Product Backlog includes usages of cases, defects, enhancements, technologies, stories, features, issues. At the beginning of the project Product Owner prepares Product Backlog, and the Scrum-team supplements this backlog with assessments of cost needed /time needed for realization of the requirements. The list should include functional and technical requirements needed for realization of the product. The most prioritized requirements should be described for their subsequent estimation and testing. To build up product backlog, Product Owner can create task group "Product Backlog" and split it to a number of sub-groups Scope of initial work on the project Grid for a game was agreed on a 10x10 grid as that is the average grid for a average phone The first trial for a game in a phone is going to between two people playing on two phones using Bluetooth Interface Should contain play, start, help, grid size, exit Scores will be displayed at the end of each game Scores can be shared using the web 5

6 There is going to be user experience e.g sounds, you have won, message and hints Players should be able to customize their application e.g background colour, fonts How to play the game Use numbers on the keypad to move around the game A conformation message should appear after pressing the restart button Memory We must check the limitations on the canvas size on different phones. If the size of our Operating system can be used by a particular phone we will chose to develop on. Poke point to automatically install/uninstall application Help file Can have documentation of how to install and uninstall manual Application should be platform independent, Spring Backlog After the planning session is over and Scrum-team has chosen and engaged itself to realize a group of requirements from Product Backlog, these requirements are broken into tasks that create a task list.this is the time that the srum team members will tell how much time they need to complete tasks on the product backlog Breakdown Breakdown of tasks will help to plan iteration in proper way and, as a result, there will be some outstanding tasks at the end of the process. After the end of detailed elaboration the estimation of Sprint Backlog is compared to a primary estimation in Product Backlog. If there is a considerable divergence, Scrum-team agrees with Product Owner about the volume of works that should be performed during iteration, and also about the volume to be shifted to the 6

7 following one. Tasks that have less importance and influence on the iteration goal will be struck out from the Sprint Backlog Sprint Burn down Chart The sprint schedule (Burn down Chart) shows daily change of total volume of the works remained before the termination of the iteration. This schedule allows the team of developers to make the analysis of a current situation and react to deviations in due time. The sprint schedule also allows Product Owner to watch over the iteration. If the total volume of works does not decrease every day, it means that something goes wrong. During the planning session the scrum teams finds and estimates tasks which should be executed for successful end of the iteration. The estimation sum of all tasks of the Sprint Backlog is the total volume of work that should be accomplished for the iteration Meetings Daily Scrum (Project status meeting) Guidelines for a meeting The meeting starts on time. Takes 15 minutes The meeting should happen at the same location and same time every day During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do today? Do you have any problems preventing you from accomplishing your goal? (It is the role of the Scrum Master to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.) Scrum of scrums Held each day, after the daily scrum meeting These meetings allow teams to discuss their work, focusing especially on areas of overlap and integration. 7

8 A designated person from each team attends. The agenda will be the following questions: What has your team done since we last met? What will your team do before we meet again? Is anything slowing your team down or getting in their way? What have you done since yesterday? What are you planning to do today? Do you have any problems preventing you from accomplishing your goal? (It is the role of the Scrum Master to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.) Sprint Planning Meeting At the beginning of the sprint cycle a 30 day, a Sprint Planning Meeting is held. Select what work is to be done Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team Identify and communicate how much of the work is likely to be done during the current sprint Eight hour limit (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog At the end of a sprint cycle, two meetings are held: the Sprint Review Meeting and the Sprint Retrospective Sprint Review Meeting (Four hour time limit) Review completed and uncompleted work Present the completed work to the stakeholders (a.k.a. the demo ) Incomplete work cannot be demonstrated Sprint Retrospective (Three hour time limit) All team members reflect on the past sprint 8

9 Make continuous process improvements Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Conclusion There are project management methodologies that can be used. The project leader must select one that can suitable for the rest of the team Reference [1] last accesed 15 may 2010 [2] last accesed 15 may 2010 [3] last accesed 15 may