Organizations looking to get started with agile software development often turn to Scrum as a place to start because of its simplicity. It is a framework for creating a development process but does not prescribe engineering practices. And, as Certified ScrumMaster Joseph Little put it, “That’s not a bug, it’s a feature.”

Before putting Scrum into place in an organization, Little said it’s critical to understand the values and principles behind the steps, or you won’t get the desired result. It’s like dancing, he added: “If you’re not feeling the music, you can do the steps, but it won’t be pretty.”

The Scrum Alliance lists four core principles based on 2001’s Agile Manifesto:

1)    Individuals and interactions over processes and tools
2)    Completed functionality over comprehensive documentation
3)    Customer collaboration over contract negotiation
4)    Responding to change over following a plan

Scrum itself is made up three roles, four ceremonies and three artifacts, according to the alliance.

The roles are product owner, ScrumMaster and team. The product owner is responsible for the business value of the project. The ScrumMaster ensures the team is functional and productive. The team self-organizes to get the work done.

The ceremonies are:

1)    Sprint planning: The team meets with the product owner to prioritize the work to be delivered during a sprint
2)    Daily scrum: The team meets each day to share struggles and progress
3)    Sprint reviews: The team demonstrates to the product owner what it has completed during the sprint
4)    Sprint retrospectives: The team looks for ways to improve the product and process

The artifacts are the product backlog, the sprint backlog and the burndown chart.

The product backlog is a list of items that can be added or deleted from the project at any time. The backlog is prioritized, with highest-priority items worked on first. The lower-priority items are loosely defined but are revisited and refined as they work their way up the priority list.

The sprint backlog is the set of items from the product backlog that the team commits to completing during the timeframe of the sprint.

The burndown chart is an at-a-glance look at the work remaining in the overall project. Some organizations maintain two burndown charts: one for each sprint, and one for the overall project.

“The key is getting results: making customers’ lives better, making workers’ lives better and having more fun,” Little said. “It’s not a religious, dogmatic thing.”