add site
services
publishers
database
health videos
toolbar
stats
live show
health store
more stuff
JOIN/LOGIN
| advertise add site services publishers database health videos
| | about toolbar stats live show health store more stuff JOIN/LOGIN |
Daltin Designs - Web Hosting, Web Site Development, Software Development phscardiology.com |
Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.[1] Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.
[edit] HistoryIn 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new holistic approach that would increase speed and flexibility in commercial new product development.[2] They compared this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases, to rugby, where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. The case studies came from the automotive, photo machine, computer and printer industries. In 1991, DeGrace and Stahl, in “Wicked Problems, Righteous Solutions,”[3] referred to this approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka. In the early 1990s, Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods. At the same time, Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and were the first to call it Scrum.[4] In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA ’95 in Austin, TX, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001, Schwaber teamed up with Mike Beedle to describe the method in the book “Agile Software Development with Scrum.” [edit] CharacteristicsScrum is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:
During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which 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 or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software. 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. There are several implementations of systems for managing the Scrum process, which range from yellow stickers and whiteboards, to software packages. One of Scrum’s biggest advantages is that it is very easy to learn and requires little effort to start using. [edit] RolesMain article: The Chicken and the Pig A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke about a pig and a chicken opening a restaurant:[5]
So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project. [edit] “Pig” rolesThe Pigs are the ones committed to the project in the Scrum process—they are the ones with “their bacon on the line.”
[edit] “Chicken” rolesChicken roles are not part of the actual Scrum process, but must be taken into account. They are people for whom the software is being built.
[edit] Meetings
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”
[edit] Artifacts[edit] Product backlogThe product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the “What” that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI is higher. The product backlog is the property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team. [edit] Sprint backlogThe sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is the property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”. [edit] Burn downThe sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the Release Burndown Chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the Alternative Release Burndown Chart[12], which basically does the same, but allows to show clearly scope changes into a Release Content, by resetting the baseline. It should not be confused with an earned value chart. [edit] Adaptive project managementThe following are some general practices of Scrum:
[edit] TerminologyThe following terminology is used in Scrum:[13] [edit] Roles
[edit] Artifacts
[edit] Others
[edit] Scrum modifications[edit] Scrum-banScrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected use stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished use stories and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way which allows for minimum completion time for each use story or programming error, and which on the other hand ensures that each team member is constantly employed. [14] To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard. [15] In the case of decentralized teams stage illustration softwares, such as ScrumWorks and (the combination of) JIRA and GreenHopper can be used to visualize each team’s use stories, defects and tasks divided into separate phases. In their simplest, the work stages are
tasks or usage stories. If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work can not be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work. [16] There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times. [17] A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.[16] The major differences between Scrum and Kanban are derived from the fact that in Scrum work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible. [18] Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied in software development at least by Microsoft and Corbis. [19] [edit] Product developmentScrum as applied to product development was first referred to in “The New New Product Development Game” (Harvard Business Review 86116:137–146, 1986) and later elaborated in “The Knowledge Creating Company” both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Today there are records of Scrum used to produce financial products, Internet products, and medical products by ADM. [edit] See also
[edit] References
[edit] Further reading
[edit] External links
[edit] Videos
| ||||||||||||||||||||||||||||||||||||||||||||
| ↑ top of page ↑ | about thumbshots |
