What is SCRUM?
At Benchcode Solutions, we develop software applications using the Scrum methodology. Scrum is an agile method for project management with an iterative approach. The Scrum methodology manages the development process through many small steps, rather than trying to plan everything upfront. Its primary goal is to maximize the customer’s ROI by creating working software rapidly and responding to changing requirements quickly.
Scrum relies on iterative development. This means that we focus on developing a product in short intervals of time (usually from two to four weeks). After each interval elapses, the direction of the project direction can be adjusted as needed to adapt to any new situation or circumstances. Each iteration is known as a “sprint” and results in software functionality that is developed and tested progressively. The software can be deployed or shipped to the end users. Clients can provide feedback on any or all of the intermediate software builds. Clients have many opportunities to change the direction of the project if warranted by changing circumstances.
The Scrum methodology facilitates an exploratory approach to software development. It releases our clients from the challenge of having to deliver full requirements documentation up front. The agility of Scrum improves the transparency of projects by providing regularly updated information on the status of software development. This ensures that no issues are swept under the carpet and all stakeholders are kept aware of the team’s progress at all times.
Scrum and Quality Assurance
At Benchcode Solutions, quality is much more than quickly putting an application together and testing it before delivery. We integrate QA work into each sprint. Instead of relying on the flawed practice of running many testing and bug-fixing cycles on software that has already been implemented, we strive to design and build systems with fewer bugs right from the start. This is made possible by automated unit testing and continuous integration – two key practices that we recommend to all of our clients for their software development projects.
Scrum Activities and Artifacts
At its core, Scrum is an iterative approach to software development. Scrum splits a large project into many time intervals known as sprints. Sprints generally last between one week and one month, averaging about 14 days. During each sprint, developers focus on a particular set of features, making the idea become reality through careful coding and testing.
Each sprint can be subdivided into smaller activities. Each sprint kicks off with a sprint planning meeting during which the team members identify the top priorities and list the ones that they can realistically perform in the product backlog.
Throughout the sprint, there are daily meetings that are capped at 15 minutes. Team members share information about their progress the previous day, their plans for the current day, and any potential obstacles. These meetings align the team members’ efforts and keep everyone’s work on track.
As the sprint draws to an end, the sprint review allows the team to demonstrate its accomplishments. The product owner and/or users are invited to view the new functionality and provide detailed feedback, which is then incorporated into the next product backlog.
The sprint retrospective occurs at approximately the same time. This is an opportunity for all the team members to discuss the process itself, sharing their thoughts about the concluding sprint and any ideas for making the next sprint more productive and more successful.
Scrum Artifacts
The Scrum methodology results in several artifacts. The most obvious is the finished product which is ready to be shared with the client and/or end user.
The product backlog is a living document that contains a full list of all the desired functionality, subject to change per the client’s needs. The product owner prioritizes the list of items and the team focuses on the highest-priority outstanding items in each sprint. The desired functionality can be listed in many different ways, but project teams find the greatest success when they are expressed as brief stories depicting the experience of the end user.
Note that the sprint backlog is a smaller subset of the product backlog. It lists only the features and functionality that the team members will focus on during a single sprint.
While tackling the list in the sprint backlog, the team members use two charts: the sprint burndown chart and the release burndown chart. These documents reflect how much work the team still has to do and function almost like a dashboard, providing a visual representation of whether the sprint or release is on track for timely completion.
Product Owner
When following the agile Scrum methodology, the product owner is the key stakeholder and a visionary with the power to share that vision with the team members. The product backlog is the product owner’s main tool for communicating the vision, as it contains a list of the product features in order of their priority for development.
The product owner needs to have a clear understanding of the market, competitors, trends, and the end users. Often the product owner is a lead end user, but it could also be someone in product development and/or marketing.
The product owner provides clear direction to motivate the team, but does not assume a role of a delegator. The team members are best suited to assign tasks for each sprint based on their skills and their understanding of how much work is involved in the development of any particular feature. The product owner develops the list of features in the product backlog and assigns priorities to them, but the team members determine which features they will focus on during each sprint.
When the team members commit to the development of certain features during a sprint, the product owner agrees not to change the requirements during a sprint. Between sprints, adjustments may be made. But during a sprint, the team’s focus must not be disturbed.
Scrum Master
Each Scrum team has a ScrumMaster who guides the process and helps the team deliver optimal results. The ScrumMaster is an expert in the Scrum methodology. He or she is able to identify and remove or mitigate obstacles, facilitate meetings, and communicate clearly with the product owner and other stakeholders.
The ScrumMaster is often someone with a background in project management, but the role can also be filled by a technical specialist. The ScrumMaster is not only a coach, but also a protector of the team. If the product owner is demanding too much, the ScrumMaster must recognize this and help the team members avoid overextending themselves. At the other extreme, if the team members become lackadaisical, the ScrumMaster must address this, too.
Although the ScrumMaster has no real authority over the other team members, he or she is the master of the process itself. The ScrumMaster cannot dismiss team members, but can control the duration and frequency of sprints. The best ScrumMasters keep the team members focused on the end goal, but they do not micromanage in attempts to control how team members perform during each sprint.
The ScrumMaster cannot control how tasks are completed or who completes them, and these limitations to power can be frustrating for those who are accustomed to more traditional roles in project management. The ScrumMaster role is challenging and critical to the success of the Scrum methodology.
The Team
Scrum teams are not hierarchical organizations. Rather, everyone collaborates to complete the development work the team has committed to performing during a given sprint. Individuals do not have assigned roles, but instead work together for the greater good.
Most Scrum teams have between five and nine members, but this varies. Larger projects are accomplished through the practice of scaling, like having Scrum teams within Scrum teams. When structured properly, such scaling can accommodate more than 1,000 people. Within this structure, each team sends one person to a “Scrum of Scrums” meeting where inter-team work is coordinated. These meetings usually occur a few times per week, but not every day as the team meetings do.