Agile Scrum Framework Basics

At Volanno, an increasing number of projects are carried out within the Agile Scrum framework. The Agile framework provides a safety net to ensure that all management and development activities are delivered in a timely manner with buy-in from the client. The Agile process incorporates basic project management principles that many clients are accustomed to seeing in traditional Waterfall projects, such as progress meetings, review of requirements, identification of key deliverables and milestones, alerts to issues and risks, and ongoing iterative and regression testing. There is often a misconception that using the Agile framework means that projects are less structured, but it is actually the opposite. All iterations in an Agile project actually follow specific guidelines in terms of organization, roles, and expected deliverables.

The Agile Scrum framework starts with a core structure, the Scrum Team. Within a Scrum Team, the following roles must be fulfilled:

• Product Owner. The Product Owner is an employee with decision-making authority, responsible for grooming and prioritizing the list of project requirements (Product Backlog).
• Scrum Master. The Scrum Master is the facilitator for the project. She ensures that all members of the team are able to complete tasks and that the Scrum process is followed.
• Development Team. The Development Team is responsible for creating tasks during Sprint Planning and assigning a level of effort to each. Once the Sprint begins, the team is responsible for completing tasks assigned, attending the daily status meeting (Daily Scrum), reporting on progress, updating the tracking tool with task status, and coordinating with other members of the team.

Basic Agile Process

The Agile Scrum framework creates an iterative environment that involves consistent refinement of the Product Backlog, testing at each increment, and review of work completed before new work commences. This approach also allows for maximum velocity from members of the Development Team as they are dedicated to the current work assigned, knowledge sharing, and immediate roadblock identification. Due to the nature of the work and the rigor of the Agile framework, a two-week Sprint is often recommended. However, teams should decide what duration is most appropriate for the complexity of the work being performed. The entire Agile process is demonstrated in the figure.

Product Backlog Development

The Product Backlog is the cornerstone of the project. The Product Owner works with the Business Analyst and Scrum Master to document the themes, features (epics), and User Stories needed by the team to create a product that adheres to the Product Owner’s vision. During the development stage, the team identifies the following components:

• Business Case: Justification for a project based on benefit.
• Vision: A picture of the future state.
• Team: Identification of core team and stakeholders.
• Storyboard: A visual descriptor of the requirements.
• User Stories: High-level definitions of the requirements.
• Release Plan: A definition of what will be delivered in releases.
• Logistics: Project operational details.
• Sprint Duration: The length of time for each Sprint.
• Definition of Done: A list of activities that verify completion (example below).

The Sprint

Throughout the Sprint, the team develops the work defined in the User Stories. As tasks are completed, their status is updated in the tracking tool. As User Stories are completed, the work is validated against the acceptance criteria, which are also updated in the tracking tool.

The Scrum Team attends the Daily Scrum, which is a 15-minute status meeting. During this time, the Scrum Master facilitates resolution of any impediments or question that may arise, and the Product Owner provides answers to product questions. Any issue that cannot be easily resolved during the Daily Scrum is taken offline and addressed immediately after the meeting.

Sprint Planning

Each Sprint begins with a Sprint Planning session that lasts the number of hours equivalent to the number of weeks in the Sprint (e.g., a 2-week Sprint requires a 2-hour Sprint Planning session). The first half of the session is used to review the Product Backlog with the Product Owner to ensure that the Development Team understands the requirements for the Sprint. During this time, points are assigned to each backlog item to ensure the Development Team does not address too many User Stories simultaneously. The second half of the session is designed for the team to create tasks and provide details needed to complete the User Stories.

Sprint Review

At the end of each Sprint, the team holds a Sprint Review. This provides the team with an opportunity to conduct an informal demo of work completed and to answer questions from the Product Owner, Product Manager, Sponsor, and stakeholders. Compared to the Daily Scrum and Sprint Planning, the Sprint Review involves a larger audience and creates an atmosphere that fosters input prior to final deployment.

Sprint Retrospective

After the Sprint Review, the Scrum Team meets for the Sprint Retrospective to discuss what worked and what didn’t. This is an opportunity for the team to make course corrections before beginning the next Sprint.