Scrum (development)

From Wikipedia, the free encyclopedia

(Redirected from SCRUM)
Jump to: navigation, search
 This article includes a list of references or external links, but its sources remain unclear because it lacks in-text citations.
You can improve this article by introducing more precise citations.
For other uses, see Scrum.
Software development process
Activities and steps
Requirements | Architecture | Design | Implementation | Testing | Deployment
Models
Agile | Cleanroom | Iterative | RAD | RUP | Spiral | Waterfall | XP | Scrum
Supporting disciplines
Configuration management | Documentation | Software quality assurance (SQA) | Project management | User experience design

Scrum is a project management method for agile software development.

The approach was first described by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). They noted that projects using small, cross-functional teams historically produce the best results, and referred to this as the "rugby approach". In 1991, DeGrace and Stahl, in "Wicked Problems, Righteous Solutions" ([1]) referred to this approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka. Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods, in the early 1990s. 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 ([2]). Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA '96 in Austin, 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. Schwaber teamed up with Mike Beedle in 2001 to write up the method in the book Agile Software Development with SCRUM.

Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach: Scrum of Scrums.

Contents

[edit] Characteristics of Scrum

  • A product backlog of prioritized work to be done;
  • Completion of a fixed set of backlog items in a series of short iterations or sprints;
  • A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
  • A brief sprint planning session in which the backlog items for the sprint will be defined.
  • A brief sprint retrospective, at which all team members reflect about the past sprint.

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences.

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 fundamentally empirical challenges cannot be addressed successfully 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.

[edit] Product backlog and sprint backlog

A backlog is a list of prioritized items to be developed for a software product. The product backlog is maintained by the Product Owner and is a list of requirements that typically come from the customer. The sprint backlog is the Team's interpretation of the product backlog and contains concrete tasks that will be done during the next sprint to implement some of the top items in the product backlog. The product and sprint backlogs are therefore two totally different things, the first containing a high-level requirement and the second containing information about how the team is going to implement the requirements.

[edit] Sprint planning

Prior to every sprint the Product Owner, the Scrum Master and the Team decide what the team will work on during the next sprint. The Product Owner maintains a prioritized list of backlog items, the product backlog, that can be reprioritized during sprint planning. The Team selects items from the top of the product backlog. They select only as much work as they can commit to finishing. The Team then plans the architecture and design of how the product backlog could be implemented. The product backlog items are then broken down into tasks that become the sprint backlog.

[edit] Scrum Roles

Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken [3]:

A pig and a chicken are walking down a road. The Chicken looks at the pig and says "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says "Good idea, what do you want to call it?" The chicken thinks about it and says "Why don't we call it 'Ham and Eggs'?" "I don't think so" says the pig, "I'd be committed but you'd only be involved"

So the pigs are committed to building software regularly and frequently, while everyone else are chickens that are interested in the project but are really irrelevant because if it fails they're not a pig, 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 not in any way letting it affect or distort or get in the way of the actual Scrum project.

[edit] "Pig" Roles

Pigs are the ones committed to the project and the Scrum process; they are the ones with "their bacon on the line".

[edit] Product Owner

Represents the voice of the customer to ensure the Scrum Team works with the right things from a business perspective.

[edit] Scrum Master (or Facilitator)

Ensure that the Scrum process is used as intended. The Scrum Master is the enforcer of rules and sprints of practice. The master protects the scrum team from impediments and distractions

[edit] Scrum Team

A small team of 5-9 people with cross-functional skills to do the actual work.

[edit] "Chicken" Roles

Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.

[edit] Users

The software is being built for someone! Never forget that software that is not used, is like a tree falling in the forest - was it ever written?

[edit] Stakeholders

The people that will enable the project, but not directly involved in the process. This includes Executives.

[edit] Consulting Experts

These are people who provide expertise that is not required on every sprint. Often these chickens will become a pig as part of the Scrum Team during some sprints.

[edit] Adaptive project management

Following are some practices for the Scrum:

  • Customers become a part of the development team. (i.e., Customer must be genuinely interested in the output.) – VOC – In SDLC parlance, validate what you have planned to develop.
  • Frequent intermediate deliveries with working functionality. – Incremental development and releases (may be internal only) – providing you an opportunity to validate and verify at shorter intervals rather than only at the end; thereby, providing you time to fix, and reducing the cost to fix.
  • Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with genuinity – Make it live, and continuous activity.
  • A daily status discussion (Standup meetings) asking each team member:
    • What have you done since yesterday? (accomplishments)
    • What are you planning to do by tomorrow? (to be accomplished)
    • Do you have any problems preventing you from accomplishing your goal? (issues/concerns/risks)
  • Transparency in planning and module development – Let everyone know who is accountable for what and by when.
  • Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders' update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time.
  • No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
  • Workplaces and working hours must be energized. – "Working more hours" does not necessarily mean "producing more output."

[edit] Scheduling daily status discussions

A popular time for the daily status discussion is after the lunch break. Doing it in the morning may be troublesome especially if the team is working in a company using flextime. These status discussions don't take long, so one way is to do standup meetings where the team meets in front of a whiteboard. Because people tend to get tired after lunch, having a lively standup meeting at that time may keep their energy up. Because everybody has already been working that day, their minds are focused on the job and not on their personal issues.

[edit] Solo Scrum

Scrum is based on small teams. It enhances communication between team members. Nevertheless, there is a huge amount of software that is developed by solo programmers. A software system being built by a single programmer can still benefit from some of the Scrum principles such as: a product backlog, a sprint backlog, a sprint and a sprint retrospective. Solo Scrum is an adapted version of Scrum for use by solo programmers.

[edit] Scrum terminology

Scrum Master: The person or persons in charge of the tracking and the daily updates for the scrum (equivalent to a project manager). Sometimes referred to as a Scrum Facilitator.
Scrum Team: A cross-functional team (developers, B.A.s, DBAs, and testers) responsible for developing the product.
Product Owner: The person responsible for maintaining the Product Backlog via continuous interaction with Clients and Stakeholders.
Story: A customer focused description of valued functionality.
Product Backlog: The stories to be completed.
Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of stories that the Team has committed to.
Sprint Backlog: The Team's interpretation of the product backlog containing concrete tasks that will be done during the next sprint to implement some of the top items in the Product Backlog.
Burn Down Chart: Daily progress for a sprint over the sprint's length.

[edit] Sources

[edit] See also

[edit] Other Agile methods

[edit] External links


[edit] Scrum in general project management

 The external links in this article may not comply with Wikipedia's content policies or guidelines.
Please improve this article by removing excessive or inappropriate external links.
Retrieved from "http://en.wikipedia.org/wiki/Scrum_%28development%29"
Personal tools