Scrum is the most widely adopted agile methodology. Using the Scrum framework, chaos is mitigated by limiting work in progress (WIP) to time-boxed iterations, allowing scope changes only on sprint boundaries, and synchronizing with the customer at the end of each sprint.
Inspect.
Adapt.
Be transparent.
In Scrum, we agree to inspect and adapt not only what we are building but how we are going about building it. We also expect that all of the information that is important to building the product is available to the people building it. And, of course, we cannot inspect and adapt (and thus continuously improve) without transparency.
Value delivery in Scrum happens in short cycles called iterations which last, typically, 2 weeks. Overall delivery goals are defined in terms of increments of business or architectural value, called stories. The expectation is that a story is (1) described in terms of its value (rather than in terms of detailed business requirements); (2) has clear acceptance criteria; and (3) is broken down sufficiently for the work of defining, building, and testing it to be completed by an agile team within a iteration.
Stories are gathered and defined by a product owner (the proxy for the customer or downstream consumer), who prioritizes them on a product backlog, works daily and dynamically with the agile team to clarify requirements just-in-time, and ultimately determines when the delivered item has met its acceptance criteria. The work of every agile team is facilitated by a scrum master, who is responsible for guiding the team in the methodology, removing impediments to their work, and making their progress visible. The team itself is a dedicated group of 3-to-7 people, which collectively compromises all of the skills and knowledge necessary to design, build, test, and deliver the desired value.
An agile team ...
is empowered.
is self-organizing.
holds each other accountable to their agreements, the methodology, and the quality of the system.
A team will churn if any of the three roles do not live up to their responsibilities.
The Product Owner gives the vision of what to work on and why; defines “Done” and accepts/reject work; engages daily with team and motivates them; manages stakeholder/sponsor expectations, and owns accountability for delivering on the overall vision.
The Scrum Master takes leadership over the process and is accountable for keeping the process healthy; holds the team accountable to the process and progress (and maintains expectations that the team hold each other accountable as well); protects the team from priorities or interruptions from outside of the sprint backlog; removes obstacles that arise during the sprint; creates visible information radiators and coaches the team how to use them to drive continuous improvement.
The team collaborates to determine how they will get deliver the planned value (tasks), who will do the work, how the team will get it done, and what the team can commit to.
These three roles (product owner, scrum master, and agile team) participate in a re-occurring series of "ceremonies" (meetings) which are intended to facilitate efficient and dynamic input about the desired future state or behavior of a system, demonstrate value, gather feedback, and provide visibility into the development process.
Below are the prescribed Scrum meetings.
Product Backlog Refinement - All desired functional features and technical capabilities are described on a backlog. The product owner (the proxy for the customer) brings the prioritized backlog to the backlog refinement meeting where the highest priority product backlog items (PBIs) are reviewed for completeness of the acceptance criteria, estimated in terms of story points (relative sizing), and split, as necessary, to fit within a sprint.
Iteration Planning - Facilitated by the scrum master, the agile team and the product owner negotiate which of the highest priority PBIs to implement in the upcoming sprint. The selected PBIs are placed on the team's sprint backlog along with any tasks needed to implement them. While PBIs are estimated in terms of story points, tasks are estimated in term "remaining hours". Both are metrics which the team monitors throughout the sprint to visualize progress. However, number of the story points delivered per sprint informs capacity planning for future sprints.
All of the following are continuous activities throughout the sprint.
Design reviews.
Code reviews.
Daily build.
Continuous testing.
Integration.
Documentation.
Prior to 2011, the Scrum Guide contained ceremonies and vocabulary related to release planning. This was later removed to highlight the fact that release planning isn't necessary to do Scrum. However, roadmap and release planning are necessary forecasting tools for most organizations. Please see the practices in the scaled agile section of this website for roadmap and release planning.
Book [online, free]: "The Scrum Guide" by Jeff Sutherland and Ken Schwaber
Book [paid]: "Essential Scrum" by Kenneth Rubin
Video [online, free]: "Introduction to Scrum" by CollabNet