Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.

Roles Responsibility
Scrum Master Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.
Delivery Team Responsible for delivering the work. The team is made up of the following roles:

  • Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
  • Requirements Manager: Elicits, refines, and manages the solution requirements
  • Architect: Defines the architecture and technologies employed by the software solution
  • Technical Lead: Oversees software design and development
  • Developer(s): Codes and integrates the software
  • Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
  • Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
  • Data Architect: Defines data architecture and allocation of data assets
  • Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration tasks

The Delivery Team will conduct sprint planning at the beginning of the project, and at the beginning of each development cycle, or sprint. Sprint planning is conducted specifically to create the Sprint Backlog and identify sprint goals (e.g., complete a specific feature).

During sprint planning, the Delivery Team selects their assignments from a backlog of development tasks, called the Product Backlog. The Product Backlog is prioritized and maintained by the Product Owner to ensure higher-value tasks are selected first. As tasks are selected from the Product Backlog, they are added to the Sprint Backlog. The Sprint Backlog represents the collection of tasks the Delivery Team has committed to for a given sprint.

Development tasks are typically presented in the form of user stories. As user stories are added to the Sprint Backlog, they are assigned story points. Story points are estimations of effort required to complete a given development task.

The regular development cycle begins once the Delivery Team has committed to the Sprint Backlog. Stand-up meetings are convened daily for team members to report on their completed tasks, tasks in progress, and any roadblocks impeding their work.  It is the Scrum Master’s responsibility to ensure all roadblocks are efficiently resolved.

At the end of each sprint, the Delivery Team will demonstrate the functionality that was completed for that sprint. The team also discusses whether the sprint goal was met and whether all the entire Sprint Backlog was completed. The story points for each completed user story are then totaled. This is the team’s sprint velocity.  The Table below demonstrates how sprint velocity is calculated.

Calculating Sprint Velocity

Completed User Stories Story Points
Completed User Story A 5
Completed User Story B 3
Completed User Story C 8
Sprint Velocity: 16

 

The sprint velocity can then be used as a benchmark for the next sprint. Based on the sprint velocity calculated in Table 2, the Development Team would commit to stories totaling no fewer than 16 story points in the next Sprint Backlog.

The sprint velocity will change with each sprint, though over time, an average velocity is determined that can reliably instruct estimates for future work.

The Delivery Team holds a retrospective at the end of each sprint to:

  • Assess overall project status
  • Identify opportunities for process improvement in subsequent sprints
  • Reviews project risks, identify mitigation strategies, and assign mitigation tasks

The new sprint begins with next sprint planning meeting. The process repeats until the Product Backlog is exhausted.

For larger projects, multiple Delivery Teams tackling separate sections of the Product Backlog will be required. In this case, an additional daily standup meeting is held with one member from each Delivery Team, also known as the Scrum of Scrums.

The Scrum of Scrums meeting follows the same format as traditional stand-up meeting: each Delivery Team representative reports on completed work, work in progress, and roadblocks impeding progress. The Scrum Master for the Scrum of Scrums is responsible for resolving any conflicts or dependencies that might emerge between the different Delivery Teams.

Partnet’s Scrum process allows all members of the Delivery Team to work on one set of tasks concurrently, resulting in faster delivery and defect resolution, and adaptability to changing requirements or business priorities.

Over time, we have tailored our Scrum approach to support specific Government processes since most of our work is done for the government. This modified Scrum process allows us to effectively deploy Agile software methodologies while ensuring all Government requirements are met during each of three, distinct phases: design, development and testing, and user acceptance testing.

Partnet employs multiple, autonomous Delivery Teams during each sprint. Each team will be separately assigned a specific subset of the development requirements with overall software integrity across teams maintained through the Scrum of Scrums process. This will allow development and testing of multiple software feature sets within a single sprint.

The use of the Scrum methodology in your defined Software Development Life Cycle is a best practice for Agile development. In my next blog I will discuss the use of Kanban, another useful Agile development methodology.