What is Scrum?

Scrum is a way for a team of people to collaborate effectively on a complex project. The Scrum process uses a small set of rules and rituals that strike a balance between establishing the structure necessary to tackle complexity while allowing the creative freedom required to innovate collaboratively. Effective software development teams adhere closely to the Scrum framework because consistent use of the process results in the best possible software outcomes.

People

PRODUCT OWNER: The Product Owner is the one-man dam that keeps the demands of the Stakeholders from inundating or distracting the Development Team. She prioritizes the workload for the project, and she communicates to the developers what should be done next and what the definition of Done is for each task.

STAKEHOLDERS: To communicate altered project goals or requests, stakeholders must go through the Product Owner. This keeps the Development Team focused on building your product.

DEVELOPMENT TEAM: These are the creators. They build your product and collaborate with the Product Owner and the Scrum Master.

SCRUM MASTER: The Scrum Master is the keeper of the rules and rituals that help to keep the Development Team on track. She meets with the team in a Daily Scrum each morning of a Sprint to check in on progress, and she works to remove any impediments standing in the way of development.

Artifacts

USER STORIES: These are the individual goals or tasks for the project. At Praxent, we phrase them as, “As a I want to so that I .” Each User Story is a self-contained piece of a major feature (or an Epic) of the project, and each Story has explicit acceptance criteria. We begin a project by defining these Epics and their affiliated User Stories, and by methodically completing these User Stories in a series of Sprints, we can monitor and quantify our success throughout the course of development.

PRODUCT BACKLOG: The collection of incomplete User Stories for a project. Often the Stories in the Product Backlog have not yet been sized or prioritized, and their acceptance criteria have not yet been clearly defined. It is primarily the Product Owner’s responsibility to sort the Stories in the Product Backlog based on business value or risk for the Stakeholders, and it is the responsibility of the Development Team to size each Story using Story Points.

SPRINT BACKLOG: A prioritized collection of User Stories that have been sized and assigned acceptance criteria, but that have not yet been tackled by the Development Team in a Sprint. Though the Sprint Backlog is a prioritized list of User Stories, its hierarchy is dynamic. This allows the Sprint Backlog to adapt to the changing demands of the Stakeholders or Product Owner or to the growing knowledge of the Development Team.

Key Concepts

DONE: The effectiveness of Scrum revolves around a clear understanding of what Done means. This applies at the lowest level to each User Story, all the way up to the product as a whole. These agreed-upon descriptions of Done-ness, or acceptance criteria, provide tangible footholds for important communication about the objectives and challenges of the project.

VELOCITY: The first two or three Sprints for a project are used to determine Velocity, or, the expected number of Story Points that can be completed over the course of a single Sprint for a particular project. Velocity is important to the Scrum process for a few reasons: (1) Velocity helps the Scrum Master and the Development Team set reasonable, accomplishable goals for subsequent Sprints, (2) it game-ifies the Sprint goals for the Development Team, encouraging them to increase their Velocity – and their output – with each new Sprint, and (3) it acts as an important measure of productivity and success over the course of the project.

Rituals

SPRINT: A two- to four-week period during which a set of User Stories are locked in for the Development Team to achieve. During a Sprint, the tasks to be completed will not change, and at the conclusion of the Sprint, the Development Team will demonstrate in the Sprint Demo that each User Story is Done according to its predefined acceptance criteria.

SPRINT PLANNING: During Sprint Planning, the Product Owner, the Development Team, and the Scrum Master work together to decide (1) what will be accomplished during the next Sprint, and (2) what the Done criteria are for each User Story.

DAILY SCRUM: This is the huddle (and yes, the term comes from rugby). Every morning throughout the course of a Sprint, the Scrum Master meets with her Development Team for no more than 10 minutes. At Praxent, we hold these meetings standing up to keep them brief. Together the Scrum Master and the Development Team review what was accomplished the day before to help meet the Sprint goal, what will be accomplished today to help meet the Spring goal, and any new roadblocks the Development Team may have run into in the last 24 hours.

SPRINT DEMO: A Sprint Demo follows each Sprint. This is when the Development Team demonstrates the work they completed during a Sprint for approval by the Product Owner. There are three possible outcomes for each User Story in a Sprint Demo. If an individual User Story meets its acceptance criteria at the Sprint Demo, it will be considered Done and marked as completed. If it doesn’t meet its definition of Done, or its acceptance criteria, the User Story will be rejected and revisited in the next Sprint. And if there are tweaks or minor adjustments to be made but the current acceptance criteria have been met, then the User Story is accepted, and a new Story is captured and discussed during the next Sprint Planning.

Bonus Terms

STORY POINTS: To better estimate a realistic workload for each Sprint, every User Story is assigned a relative point value. For example, each Sprint for a particular project might contain 18 points, but Sprint A could consist of a larger 13-point Story and a smaller 5-point Story, while Sprint D might be six 3-point Stories. Point values equate to the effort and energy each User Story will require to develop, but they don’t directly translate to the number of working hours. And because Point values are assigned based on relative difficulties within each project, a User Story for one project might have a different Point value than a similar story in another project. Story Points help us quantify our Velocity and productivity at each step of development.

BURNDOWN CHART: By tracking the completed User Stories and their point values, a graph can be plotted measuring the Development Team’s progress over time. (Imagine Time on the x-axis and Total Story Points Remaining on the y-axis.) This graph provides information about the Development Team’s velocity (points achieved per Sprint) as well as accurate estimates about the remaining duration of the project.