SCRUM methodology in web development

What is SCRUM?

Scrum is an agile approach to software development. It has been adopted and modified by software development firms, digital agencies, and in-house team to develop websites and applications.

Rather than a full process or methodology, it is a framework or guide. So instead of providing complete, detailed descriptions of how everything is to be done on a project, much is left up to the project team.

This is done because the team will know best how to solve the problems posed. This is why, for example, a 'sprint planning' meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Scrum relies on a self-organising, cross-functional team. The scrum team is self-organising in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are determined by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from an idea to implementation is involved.

These teams are supported by two specific individuals: a Scrum Master and a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform to their highest level. The product owner represents the business, customers or users and guides the team towards building the right product.

Scrum projects make progress in a series of sprints, which are time-boxed iterations no more than a month long. At the start of a sprint, team members commit to delivering several features that were listed on the project’s product backlog. At the end of the sprint, these features are done - they are coded, tested, and integrated into the evolving product or system.

At the end of the sprint, a sprint review is conducted during which the team demonstrates the new functionality to the product owner and other interested stakeholders who provide feedback that could influence the next sprint.

SCRUM Team

Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect.

Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. As a result Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

A typical Scrum team is 5-9 people. Rather than scaling by having a large team, Scrum projects scale through having groups of teams.

Although not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting.

With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams.

These meetings are analogous to the Daily Scrum Meeting but do not necessarily happen every day. In many organisations, having a Scrum of Scrums meeting two or three times a week is sufficient.

SCRUM Master

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum.

The ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint.

The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings.

The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.

Product Owner

The Product Owner (typically someone from a Marketing role or a key user in internal development) prioritises the 'Product Backlog' (a very detailed 'to-do' list).

The Scrum Team looks at the prioritised Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog.

In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint.

Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint, it remains maniacally focused on the goal of that sprint.

Product Backlog

The Product Backlog is the master list of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements.

Typically, a Scrum team and its product owner begin by writing down everything they can think of quickly. This is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.

Product backlog items can be technical tasks or more user-centric. The product backlog can also be expressed in the form of user stories, which are a technique borrowed from Extreme Programming, another agile process.

The product owner shows up at the sprint planning meeting with the prioritised product backlog and describes the top items to the team. The team then determines which items they can complete during the coming sprint.

The team then moves items from the Product Backlog to the Sprint Backlog. In doing so, they expand each Product Backlog item into one or more Sprint Backlog tasks so they can more effectively share work during the Sprint. Conceptually, the team starts at the top of the prioritised Product Backlog list and draws a line after the lowest, of the high priority items they feel they can complete.

In practice, it is not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

Sprint Review

At the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting.

A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.

How does SCRUM Methodology benefit the web industry?

Due to the dynamic nature of projects in the web development industry, the following reasons are as to why this methodology would be beneficial:

• Agile Scrum helps the company in saving time and money.
• Scrum methodology develops camaraderie within members of the team.
• Scrum methodology enables project’s where the business requirements documentation is hard to quantify to be successfully developed.
• Fast-moving, cutting edge developments can be quickly coded and tested using this method, as a mistake can be easily rectified.
• It is a lightly controlled method which insists on frequent updating of the progress in work through regular meetings. Thus there is clear visibility of the project development.
• Like any other agile methodology, this is also iterative. It requires continuous feedback from the user.
• Due to short sprints and constant feedback, it becomes easier to cope with the changes.
• Daily meetings make it possible to measure individual productivity. This leads to an improvement in the productivity of each of the team members.
• Issues are identified well in advance through the daily meetings and hence can be resolved speedily.
• It is easier to deliver a quality product in a scheduled time frame.
• Agile Scrum can work with any technology/ programming language but is particularly useful for fast-moving web 2.0 or new media projects.
• The overhead cost in terms of process and management is minimal, thus leading to a quicker, cheaper result.