TheScrumDevelopmentProcess.doc

1、1The Scrum Development Process.1The Daily Scrum.2Product Backlog.3The Product Owner.4Release Burndown .5ScrumMaster.6The Scrum Team.6Sprint Backlog .7Sprint Planning Meeting .8Sprint Review Meeting .9Task Boards .9Scrum Illustration .13The Scrum Development ProcessScrum is an agile process for devel

2、oping software. With Scrum, projects progress via a series of month-long iterations called sprints. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements. The work to be done on a Scrum project is listed in the Product Backlog, which is a list of all desired chan

3、ges to the product. At the start of each sprint a Sprint Planning Meeting is held during which the Product Owner prioritizes the Product Backlog and the Scrum Team selects the tasks they can complete during the coming Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog.

4、 Each day during the sprint conducts a brief daily meeting called the Daily Scrum, which helps the team stay on track. At the end of each sprint the team demonstrates the completed functionality at a Sprint Review Meeting. Graphically, Scrum looks something like this: The following Scrum topics are

5、available: Daily scrum Product backlog Product owner Release burndown ScrumMaster 2 Scrum team Sprint backlog Sprint planning meeting Sprint review meeting Using a task board Scrum illustrations and wallpapers The Daily Scrum On each day of a sprint, the team holds daily meetings (“the daily scrum”)

6、. Meetings are typically held in the same location and at the same time each day. Ideally the daily scrums are held in the morning as they help set the context for the coming days work. There is an old joke in which a chicken and a pig are talking and the chicken says, “Lets start a restaurant.“ The

7、 pig replies, “Good idea, but what should we call it?“ “How about Ham and Eggs“ says the chicken. “No thanks,“ says the pig, “Id be committed, youd only be involved.“ The joke is meant to point out the difference between those who are committed on a project and those who are only involved. Scrum aff

8、ords special status to those who are committed and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum. All team members are required to attend the daily scrum. Anyone else (for example, a departmental VP, a salesperson, or a developer from anot

9、her project) is allowed to attend but is there only to listen. This makes the daily scrums an excellent way for a Scrum team to disseminate status information-if youre interested in hearing where things are at, attend that days meeting. The daily scrum is not used as a problem-solving or issue resol

10、ution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum. During the daily scrum each team member provides answers to the following three questions: 1. What did you do yesterday?2. What will you do today?3. Are there a

11、ny impediments in your way?By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains. The daily scrum is not a status update meeting in which a boss is collecting information about who i

12、s behind schedule. Rather, it is a meeting in which team members make commitments to each other. If a programmer stands up and says “Today I will finish the data storage module“ everyone knows that in tomorrows meeting he will say whether or not he did finish. This has the wonderful effect of helpin

13、g a team realize the significance of these commitments and that their commitments are to each other, not to some far-off customer or salesman. 3Any impediments that are raised become the ScrumMasters responsibility to resolve as quickly as possible. Typical impediments are: My _ broke and I need a n

14、ew one today. I still havent got the software I ordered a month ago. I need help debugging a problem with _. Im struggling to learn _ and would like to pair with someone on it. I cant get the vendors tech support group to call me back. Our new contractor cant start because no one is here to sign her

15、 contract. I cant get the _ group to give me any time and I need to meet with them. The department VP has asked me to work on something else “for a day or two.“In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues) he still takes res

16、ponsibility for making sure someone on the team does quickly resolve the issue. Product BacklogThe Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requi

17、rements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers. During the Sprint Planning Meeting the Product Owner prioritizes th

18、e items in the Product Backlog and describes them to the team. The team then determines which items they can complete during the coming Sprint. The team then moves items from the Product Backlog to the Sprint Backlog. In doing they expand each Product Backlog item into one or more Sprint Backlog tas

19、ks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritized Product Backlog list and draws a line after the lowest of the high priority items they feel they can complete. In practice it is not unusual to see a team select, for example, th

20、e top five items and then two items from lower on the list but that are associated with the initial five. Product backlog items can be technical tasks (“Refactor the Login class to throw an exception“) or more user-centric (“Allow undo on the setup screen“). A very interesting prospect is expressing

21、 Scrum backlog items in the form of Extreme Programmings User Stories. An example Product Backlog from a real project appears as the following: 4This Excel spreadsheet shows each product backlog item assigned a general priority (Very High, High, etc.) by the Product Owner. Estimates have been develo

22、ped by the developers but it is understood that they are very imprecise and are useful only for rough assignments of tasks into the various sprints. The Product OwnerThe Product Owner (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog. The

23、 Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog. In return for their commitment to completing the selected tasks (which, by definition, are the most important to the produ

24、ct owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint. 5Re

25、lease BurndownOn a Scrum project, the team tracks its progress against a release plan by updating a release burndown chart at the end of each sprint. The horizontal axis of the release burndown chart shows the sprints; the vertical axis shows the amount of work remaining at the start of each sprint.

26、 Work remaining can be shown in whatever unit the team prefers-story points, ideal days, team days, and so on. My preference is for story points, for all of the reasons described in the Agile Estimating and Planning book. On this burndown chart, the team started a project that was planned to be elev

27、en two-week sprints. They began with 200 story points of work. The first sprint went well and from the chart you can infer that they had around 180 story points of work remaining after the first sprint. During the second sprint, however, the estimated work remaining actually burned up. This could ha

28、ve been because work was added to the project or because the team changed some estimates of the remaining work. From there the project continued well. Progress slowed during sprint 7 but then quickly resumed. This type of release burndown chart works very well in many situations and in many teams. H

29、owever, on projects with lots of changing requirements you may want to look at an alternative release burndown chart. 6ScrumMasterThe ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not overc

30、ommit themselves to what they can achieve during a sprint. The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings. The ScrumMaster role is typically filled by a project manager or a technical team leader bu

31、t can be anyone. The Scrum TeamScrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams

32、 develop a deep form of camaraderie and a feeling that “were all in this together.“ A typical Scrum team is 6-10 people but Jeff Sutherland has scaled Scrum up to over 500 people and I have used it with over 150. The primary way of scaling Scrum to work with large teams is to coordinate a “Scrum of

33、Scrums.“ With this approach each Scrum team proceeds as normal but each team also contributes one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organ

34、izations, having a Scrum of Scrums meeting two or three times a week is sufficient. The illustration below shows how a Scrum of Scrums approach allows Scrum to scale up (in this case to 243 people). Each cell represents one person on a Scrum team. The bottom of this illustration shows teams with nin

35、e developers on them. One person from each team (the differently colored cell) also participates in a Scrum of Scrum to coordinate work above that team. Then from those nine-person teams another person is selected (this time shown with diagonal lines) to participate in what might be called a Scrum o

36、f Scrums of Scrums. 7Sprint BacklogThe sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner and the teams perce

37、ption of the time it will take to complete the various features. It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to. The sprint backlog is very commonl

38、y maintained as an Excel spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of the Sprint Backlog in Excel looks like this: During the Sprint the ScrumMaster maintains the sprint backlog

39、by updating it to reflect which tasks are completed and how long the team thinks it will take to complete those that are not yet done. The estimated work remaining in the sprint is calculated daily and graphed, resulting in a sprint burndown chart like this one: 8The team does its best to pull the r

40、ight amount of work into the sprint but sometimes too much or too little work is pulled in during the Sprint planning meeting. In this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 6

41、00 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully.

42、Sprint Planning MeetingThe Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives. During the sprint planning meeting the product owner describes the highest priority features to the tea

43、m. The team asks enough questions during this meeting so that they can go off after the meeting and determine which tasks they will move from the product backlog to the sprint backlog. The product owner doesnt have to describe every item being tracked on the product backlog. Depending on the size of

44、 the backlog and the speed of the team it may be sufficient to describe only the high priority items, saving the discussion of lower priority items for the next sprint planning meeting. Typically, the Scrum team will provide guidance when they start to get further into the backlog list than they kno

45、w could be done in the next sprint. Collectively, the Scrum team and the product owner define a sprint goal, which is a short description of what the sprint will attempt to achieve. The success of the sprint will later 9be assessed during the Sprint Review Meeting against the sprint goal, rather than against each specific item selected from the product backlog. After the sprint planning meeting, the Scrum team meet