Scrum

Scrum is an iterative incremental process of software development commonly used with agile software development. Despite the fact that "Scrum" is not an acronym, some companies implementing the process have been known to adhere to an all capital letter expression of the word, i.e. SCRUM. This may be due to one of Ken Schwaber's early papers capitalizing SCRUM in the title.
Meetings
Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a "scrum", or "the daily standup". The scrum has specific guidelines:
• The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck.)
• All are welcome, but only "pigs" may speak.
• The meeting is timeboxed at 15-20 minutes depending on the team's size.
• All attendees should stand (it helps to keep meeting short).
• 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 by today?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)
Sprint Planning Meeting
At the beginning of the sprint cycle (every 15–30 days), a "Sprint Planning Meeting" is held.
• Select what work is to be done.
• Prepare the Sprint Backlog that detail 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.
Sprint Review Meeting
At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective"
• Review the work that was completed and not completed.
• Present the completed work to the stakeholders (a.k.a. "the demo").
• Incomplete work cannot be demonstrated.
• Four hour time limit.
Sprint Retrospective
• All team members reflect on the past sprint.
• Make continuous process improvement.
• Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
• Three hour time limit.
Artifacts
Product backlog
The 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. prioritised 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 property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.
Sprint backlog
The sprint backlog is a greatly detailed 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 16 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 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".
Burn down
The 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.
It should not be confused with an earned value chart.
Adaptive project management 
The following are some general practices of Scrum:
• Customers become a part of the development team (i.e. the customer must be genuinely interested in the output.)
• Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
• Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.
• Transparency in planning and module development—let everyone know who is accountable for what and by when.
• Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)
• There should be an advance warning mechanism, i.e. visibility to potential slippage or 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."