Scrum Development Methodology Fundamentals

An overview of the Scrum development methodology manifesto, framework, roles, ceremonies and artifacts.

Agile / Scrum Manifesto

The Agile “Manifesto”

Agile methodologies, and Scrum as the most commonly used method, started with a simple manifesto, which is itself a comparison to the Waterfall methodology.

Framework

The Scrum Framework

The Scrum methodology is iterative and centers on a development cycle called “Sprints”. Sprints are short in duration, typically one to two weeks long. During each Sprint a set of features, defined as User Stories. Each User Story is a single feature.

The Product Backlog

User Stories are created within the Product Backlog, which is a repository into which all work to be completed by the development team for a software product. The Product Backlog is ordered based on the priority of each item in the Backlog. Completion of all work in the Product Backlog may take a single Sprint (albeit unlikely) or multiple Sprints (far more likely).

The Product Owner is responsible for managing the Product Backlog, and as part of that responsibility the Product Owner continually “grooms” the Product Backlog. Grooming the Product Backlog entails re-prioritizing items, pruning items that are no longer relevant, and adding new items.

The Sprint Backlog

Prior to the start of each sprint, items are moved from the Product Backlog into another repository called the “Sprint Backlog”. The Sprint Backlog, as the name implies, contains all items the development Team intends to complete during the Sprint.

The Scrum methodology states that the decision about what items to complete in each Sprint is the development Team’s to make. In reality, the Product Owner typically communicates to the Team what items should be completed and the Team’s role is only to ensure they are capable of completing all items the Product Owner prioritizes.

The Sprint

A Sprint is a development cycle in which an iteration of the software is created, meaning that those items – features defined as User Stories – are coded, tested and meet the definition of done – the acceptance criteria – during the sprint.

Roles

The Scrum Roles

The Scrum methodology is not prescriptive as a process, but defines job roles, “ceremonies” (meetings or events) and “artifacts”. Below are the definition of the three roles.

The Product Owner

The Product Owner is the project’s stakeholder and the voice of the customer. This role defines who (the customer), the why (what problem or need the customer has) and the what (what functionality is to be developed to address the problem/need. Key tasks of a Product Owner are:

• Setting product goals.
• Ensuring that the backlog is loaded with sufficient work to keep the team busy and that the backlog is “groomed” (prioritized).
• Collect and synthesize customer feedback.
• Agree upon goals for each development sprint.

The Scrum Master

The Scrum Master is responsible for managing the development process itself, holding other team members accountable for adherence to the Scrum framework and values. The Scrum Master’s primary job is to maximize the “velocity” of the team (the volume of work completed in each sprint). That sounds simple at first blush, but much is involved, including:

• Ensuring the product owner has loaded the product backlog with sufficient work for the coming sprint(s).
• Ensuring that the features (user stories… see below) have acceptance criteria, called a “definition of done”, such that once the sprint starts, clarification of requirements will not be necessary.
• Identifying “impediments” that block the progress of each team member and resolving those impediments with haste or reprioritizing work to avoid the impediment.
• Ensuring that product and sprint goals are defined and measurable and that the team fully understands them.
• Ensuring that all team members understand all story requirements and acceptance criteria.
• Handling team conflict and resolving it such that the team works harmoniously.
• Identifying opportunities to improve the application of the Scrum methodology and instituting changes.
• Managing whatever system is used to plan, manage and track development.

The Team

The “team” includes any people who will complete work in order to achieve a sprint’s goals. Team members are not static. One sprint may require a specialist in some area of technology. Thus, teams are formed ad hoc and may change over time. But they always include everyone who has work assigned to them including UX/I Designers, Software Engineers/Developers and Quality Assurance Engineers.

Ceremonies

Scrum Ceremonies

The Scrum methodology is not prescriptive as a process, but defines job roles, “ceremonies” (meetings or events) and “artifacts”. Below are the definition of the five ceremonies.

The Sprint

The Scrum methodology centers on sprints, which are short development cycles in which specific features are developed and tested to the point that those features are customer-ready. The length of a sprint is not dictated by the methodology, but most organizations use one or two weeks, with some going as high as four weeks, although that’s less common and typical only of inexperienced agile development teams.

Longer sprints are typically chosen because the organization believes that the time required for the ceremonies is the same regardless of sprint length and they want to minimize meetings as a percentage of the total work time in each sprint. This is a common mistake.

Sprint Planning

Spring planning happens prior to the start of each sprint as the name suggests. During this meeting, the team selects the stories to be completed in a given sprint, estimates each one, and ensures that the amount of work in each sprint is the same or slightly greater than their historic velocity (i.e. the amount of work they’ve been able to complete on average in the past few sprints). The longer the sprint, the longer the sprint planning meeting. Shorter is better so that no team members feel overwhelmed by the amount of work to be done.

Daily Scrum (Stand-Up Meeting)

The Scrum methodology states that daily scrum meetings, called “stand-ups”, happen on every work day during a sprint. These meetings are called “stand-ups” because the intention is that no one get too comfortable during the meeting. The meeting is as short as possible, typically one minute per participant. The participants are every member of the team, the product owner and the scrum master, who leads the meeting.

In the meeting, each team member answers the same three questions:

• What did you accomplish yesterday?
• What do you plan to accomplish today?
• What impediments are blocking your ability to make today’s accomplishments?

The intention is that every team member is making a commitment to his team mates about what he will contribute towards the sprint goals. It’s also the scrum master’s opportunity to identify impediments, and determine if those impediments can be quickly resolved or if priorities need to be adjusted. Impediments can be simply such a a developer waiting for a user interface design asset from a designer. They may also be bigger such as a critical defect that is blocking further development until it is resolved.

Impediments are NOT resolved in the standup. No reason to waste the time of every team member if only a couple are needed to handle an impediment.

Sprint Review

Sprint reviews happen after each sprint is completed and are “show and tell” sessions led by the team to demonstrate what they accomplished during the sprint to stakeholders. These meetings are meant to be celebratory… a time to take pride in one’s work and receive accolades from others.

Sprint Retrospective

Retrospectives are held by the scrum master and include all team members and the product owner. the goal of the meeting is to discuss what in the development process is working, what is not, and identify ways to improve. The Scrum methodology dictates that these meetings occur after each sprint, but in reality most organizations conduct them ad hoc.

Artifacts

Scrum Artifacts

The Scrum development methodology is not prescriptive as a process, but defines job roles, “ceremonies” (meetings or events) and “artifacts”. Below are the definition of the three artifacts.

Product Backlog

The product backlog is a prioritized list of everything that needs to be built in your product. It consists primarily of user stories, but many organizations also include improvements, escaped defects (those that made it to production), and tasks to be completed that don’t deliver functionality but do consume time from the team. The product backlog is “groomed” by the Product Owner. “Grooming” is the term used for re-prioritizing items in the product backlog and removing items that are no longer relevant.

Sprint Backlog

The sprint backlog are those items pulled from the product backlog to be completed in a given sprint. Typically, the sprint backlog is populated with items from the top of the backlog because those represent the highest priority items. However, the Team may elect to pull items from lower in the product backlog under a couple of situations:

1. If the velocity of the team is such that the team would not be able to complete a given product backlog item, so they pick one lower in priority that is smaller.
2. If an item lower in the product backlog is related to another item that has already been added to the sprint backlog. For example, the number one item in the product backlog is a story to “login” to and application. Further down the product backlog is a story to “reset my password”. While the latter story isn’t as high priority, given that the team will be working on use registration functionality, they may elect to complete all items for that “epic” in a given sprint.

The Increment

The increment is the result of a completed sprint. All items that meet the definition of done at the end of the sprint are part of the increment. Not to be confused with a “release”, because the latter likely includes multiple increments.