Guide: Agile Project Management With Scrum

Manuela Lenz

There's a very good reason why Scrum has become one of the most well-known and popular project management methods, namely, its efficiency and clarity. Taking the agile approach to project management entails building step by step and incorporating changes and modifications along the way to improve the end result or product for all involved. With a description like that, who wouldn't be interested?

Working in a multidisciplinary team means that projects can be implemented both quicker and more efficiently. In particular, scrum is noted for its provision of regular feedback and implementation of internal checks to ensure maximum flexibility and productivity. As such, it has become a very popular choice in the world of software development.

What Is Scrum?

Scrum is an agile project management framework that has seen a lot of application in the world of software development, but also for the creation of non-software products and services. Essentially, Scrum follows an incrementally cyclical (or iterative) process, meaning, that with each iteration (commonly referred to as a 'sprint'), a finished and functional component (iteration) is made available.

As their name implies, sprints (lasting no longer than a month) allow a team to complete work on what might be termed a 'sub-assembly' or component of a larger, overarching product. Scrum teams are arranged in an interdisciplinary fashion and self-organize throughout the entire process, meaning that they can take on multiple tasks or assignments, depending on how quickly they complete existing tasks.

In Scrum, a project's overriding goals and direction are pre-determined, however, the individual assignments and tasks needed to reach those goals are easily modified or changed. In other words, the destination is set, but how the team gets there is (almost) entirely up to them.

The term "scrum" comes from Rugby and refers to when a match resets after a stoppage in play has occurred owing to a penalty or foul. Its roots can be traced back to 1986 and an article in the Harvard Business Review, entitled "The New New Product Development Game“ authored by Ikujiro Nonaka and Hirotaka Takeuchi, two Japanese professors. In their article, the authors detail a team-based, scalable procedure for holistically developing products that had been used by well-known companies such as Canon, Fuji, or Honda, yielding impressive results.

Building on Nonaka and Takeuchi's work, in the 1990s, US software developers Ken Schwaber and Jeff Sutherland sought to determine (first separately, and then later, together) how to develop products quicker and more flexibly.

In 2001, Schwaber and Mike Beedle published "Agile Software Development with Scrum", the first book written about the technique. Two years, Schwaber released "Agile Project Management with Scrum" and started certifying the first "scrum masters". In his third book "The Enterprise and Scrum", Schwaber took a closer look at introducing Scrum in development teams and rolling it out across entire organizations.

Principles of Agile Software Development With Scrum

To ensure that learning continuously takes place within a team, Scrum relies on a set of principles, or values, all of which seek to foster greater responsibility and productive independent thought.

Scrum's five core values are:

  • Courage to pursue a goal, accept risks and challenges, be open to changes, and accept the consequences of (one's own) decisions.
  • Commitment to implement plans intended to achieve the desired result of an iteration. Scrum calls for ensuring that all team members have the tools needed to reach the desired goals.
  • Openness, or a transparent environment where information flows freely and is made available to all project collaborators.
  • Focus, or the contribution of all energy and experience towards specific tasks that enhance productivity and help realize the end goal.
  • Respect for all collaborators within a team, as well as their varied experiences, backgrounds, and viewpoints.

Of course, it's important that all five of these values not be blindly adhered to, even though they all have their merits. Rather, the principles help form a framework that offers a gauge for ranges of activity and approaches, ensuring that teams can achieve greater success and efficiency.

How Does Project Management With Scrum Work?

As might be interpreted from the last section, the two greatest obstacles to the successful implementation of a Scrum framework are a lack of flexibility in regards to processes and time management, as well as poor communication within teams. To offset these, Scrum focuses on developing products with the highest level of customer satisfaction, ensured by the continuous integration of changes or modifications, lending it an 'agile' quality.

In comparison to other project management frameworks, Scrum is truly 'agile', since it revolves around the following:

  • Three roles within Scrum teams
  • Five kinds of activities that occur within a set schedule (timebox)
  • Three artifacts
  • One definition of 'done'

Below, we'll go into each of these in greater detail.

1.

Roles

A Scrum project is usually made up of one or more teams, each of which is composed of members holding one of three roles. These are:

Product Owner

This person is responsible for all issues relating to the product's development. The product owner assumes contextual or subject-matter leadership of the project, and represents the employers and/or stakeholders. Product owners decide how the product should look, what functionalities it should have, as well as in which order these should be completed.

The product owner is also responsible for the quality of the product and must ensure that time is always used as efficiently as possible. They work together with the Scrum Master and the development team, and so, need to be available for questions or addressing concerns at all times.

The main responsibilities of a product owner are:

  • Participation in planning the daily scrum
  • Handling the product backlog
  • Interacting with the development team and stakeholders
  • Organizing economic aspects
  • Defining and monitoring the acceptance criteria

Good to know: The product owner is sometimes humorously referred to as the "single chokable neck", or SCN. This is because the product owner alone determines which aspects of the project should be worked on when and how. Should the development team's results not meet the stakeholder's expectations, the product owner will be called to answer and likely, make changes to how the development team is working.

Scrum Master

The Scrum master is the most versatile role within a Scrum team. This individual must help all participants to 'live' Scrum's values, principles, and best practices while working so that the project can continue to be agile and dynamic.

This role is distinct from that of the product owner, even though both work together closely and support one another.

Good to know: Since multiple roles are frowned upon in scrum, the Scrum master should never perform tasks that a team member would. More information about this topic can be found here.

It's best to designate only those with considerable experience and expertise in Scrum as Scrum masters.

Their primary responsibilities are:

  • To serve as coach and mediator (facilitator) for the Scrum team
  • Advise in organizational development matters
  • Assume responsibility for the process and its implementation
  • Moderate Scrum meetings
  • Overcome challenges and resolve issues (i.e. secure needed hardware or clear channels of communication)
  • Protect against disruptions (during sprints)
  • Ensure that information flows between the product owner and development team are clear and transparent

Development Team

The development team is primarily responsible for implementing the project and is typically composed of between five and nine developers and/or specialists. The team's tasks are assigned by the product owner, who ensures that they are completed in a specific order or arrangement, however, the development team usually organizes how best to complete the tasks it has been assigned. They must be capable of achieving sprint goals without having to rely upon the results of other teams or project members.

Generally, development teams are cross-functional, meaning that regular employees work together with specialists (i.e. programmers, architects, database administrators, etc.). In this way, everyone can contribute to the project and offer different skill sets.

The main responsibilities of a development team are:

  • Adhering to the agreed-upon quality standards
  • Participating in the daily Scrum meeting (status review)
  • Updating unfinished tasks in the sprint backlog (daily)
  • Actively advising the product owner
  • Identifying and selecting the tools needed to complete unfinished work
  • Monitoring progress and seeking to improve upon existing work
2.

Artifacts

In Scrum, artifacts help to steer a project and provide an overview of what has already been completed, and what remains to be done. Most importantly, they provide transparency concerning the product and its status, allowing for essential information to be exchanged among the collaborators on a project. In Scrum, there are three artifacts, namely:

Product Backlog

The product backlog is an organized list of all requirements for the product under design and is drafted by both internal and external stakeholders. The product owner is wholly responsible for ensuring that the product or project in development matches these requirements.

The product backlog is comprised of backlog items (i.e. user stories, epics, specifications, or bugs) that describe the customer's needs and requirements in a readily comprehensible manner. Individual points are prioritized based on their economic usefulness, risk, difficulty, and necessity, with the most important elements appearing near the top.

Hint: In its most basic form, a product backlog can be little more than a simple Excel spreadsheet. Recently, a number of practical tools that specialize in providing this functionality have been developed.

Sprint Backlog

The sprint backlog is a list that is created during sprint planning for the development team to handle. It includes all backlog items that have been selected for the current sprint, as well as any accompanying tasks that can be expounded upon during the sprint.

The sprint backlog provides a regularly updated overview of the development team's status and progress, and how close they are to achieving the intended goals. As such, it serves as a kind of real-time reporting tool for all team members.  

Increment

An increment is a partial result within a project that needs to be functional and meet the definition of 'done' (DOD) as set by the product owner. It entails the sum of all product backlog entries implemented within a sprint.

Good to know: In Scrum, the definition of done (DOD) indicates that a built product is 'ready to ship'. This can relate to a product backlog item, sprint, or even release. Most frequently, before declaring anything as 'done', it is controlled by the development team against a checklist to ensure that it truly is finished.

3.

Activities

Last but not least, we'll go into a bit more detail concerning activities or events in Scrum. These occur at set times, so-called "timeboxes".

Sprint

As mentioned throughout this article, Scrum is an iterative-incremental process that is comprised of regular and repetitive work segments that build upon one another. Such time-limited iterations or cycles are referred to as 'sprints', and can last a few days to an entire month. Their only commonality is that they have fixed start and end dates, and follow one after the other.

The goal of a sprint is the development, creation, and testing of a functional prototype or test product (increment).

Good to know: In agile software development, sprints conclude after a maximum of 30 days. At present, the trend has been towards two-week-long sprints.

Sprint Planning

During sprint planning, all members of the Scrum team (product owner, Scrum master, and development team) come together to discuss and plan tasks for the coming sprint. For a four-week sprint, the planning timebox shouldn't exceed eight hours, broken down into two four-hour segments:

  • Part 1: The product owner will introduce the development team to the backlog points for the coming sprint, and go into a bit more detail regarding contextual/technical requirements. Near the end of this segment, sprint goals will be decided upon together, and a forecast will be made regarding the amount of work and feasibility.
  • Part 2: The team decides upon how the requirements should be implemented and which steps are necessary to reach the desired goals. The previously-selected backlog points are broken down into tasks and defined more precisely. In this manner, a sprint backlog is created, linking the backlog points with a general plan for the product's functionality.

Daily Scrum

The daily Scrum is a regular status meeting lasting around 15 minutes and held between all Scrum team members. It takes place at the same time and location every day and serves to help synchronize all work for the ongoing sprint, as well as to ensure that all goals are being pursued (properly).

Development team members will be expected to be able to answer the following questions during a daily Scrum meeting:

  • What have I completed since the last daily Scrum that contributes to the overarching sprint goal?
  • What will I complete before the next daily Scrum meeting?
  • Which challenges/difficulties are preventing me from completing my tasks?

Sprint Review

The sprint review is held at the end of a sprint and helps to present and formalize the sprint's results. Any new features which have been developed for the product are detailed and later expanded upon.

In addition to the Scrum team, potential users, investors, management representatives, and other stakeholders can be present in order to gain more information about the project, provide feedback, or voice any wishes for changes or modifications. Ideas for additional features are discussed by all in attendance.

Sprint Retrospective

The sprint retrospective is convened after the sprint review and prior to the next sprint planning session. During this, the Scrum team will review the work process(es) of the previous sprint, and adapt it/them for the upcoming one. Since Scrum focuses upon continually improving all processes and boosting efficiency and effectiveness, this step is necessary.

Any measures agreed upon in the sprint retrospective are planned and documented for implementation in the upcoming sprint. For a four-week sprint, the retrospective should not last longer than three hours.

Conclusion

Scrum is an agile project management method, highly useful for developing complex systems or products. This approach is noted for its flexibility and adaptability to changes. In this manner, new ideas can be quickly implemented and incorporated into existing workflows. As a combination of planned and agile approaches, Scrum offers a sensible alternative to more established project management methods that have difficulty adapting to the demands of the modern work environment.

Author Manuela Lenz
Manuela Lenz is a trained IT specialist and worked for 20 years as a system administrator and project manager for large companies. Since 2017, the IT specialist has been a passionate IT-author. For EXPERTE.com she writes about project management, software and IT security.
Other languages:
Deutsch