Scrum for a Software Development Project

Lots of new development approaches were introduced to fit the needs of software companies. Most software development companies nowadays aim to produce high-quality software at a low cost and within a short time frame. Software development has become more complicated in recent years, with customer requirements demanding frequent changes and traditional software development life cycle approaches unable to keep up. Given this problem, agile methods were introduced to meet the new requirements of software development companies.

There are many Agile methods being used today, for example, Scrum. Thereby Scrum is probably the most popular framework that people and organizations use for software development. In the last decade, Scrum has transformed from a project management methodology to a way of understanding how dysfunctional teams, departments, and entire organizations are managed. Numerous studies have shown that when following the Scrum framework, companies have increased employee satisfaction, higher quality of code, and improved transparency regarding the current status of the project.

In order to maintain success in today’s business world, the need for fast development and high-quality content is imperative. Organizations these days are being asked to react quickly to technological developments in their industries, and many of them are feeling a lot of pressure related to adapting the business better. In a rapidly changing world, it’s more important than ever to be able to deliver high-quality products at lower costs. To meet this demand, many companies have already realized the benefits of agile methods and adopted them.

To demonstrate the advantages and the overall process of Scrum, we will look into how Scrum would be implemented for the development of an Enterprise-Resource Planning (ERP) system. ERP systems are the backbone of most modern companies and should ideally be in place to support many processes and workflows. The endless functional possibilities an ERP system offers ensure that employees are able to do their jobs in the most efficient way possible. However, they are also among the most expensive and laborious architectures in a company’s IT landscape. Agile management frameworks, like Scrum, were specifically designed to enable large and complex projects such as ERP systems to be successfully implemented.

It is possible to spend more than a year on ERP development, or it could become a permanent work site. One big reason that traditional development processes are not sufficient is that the integration and acceptance tests take place at the end of development. This means that at the end of the project, it can take a lot of time and money to fix the problems and change requests that occurred. Agile methods like Scrum can, by design, circumvent some of these problems.

Primer on Scrum

Before we start discussing the specifics of how Scrum can be utilized for developing an ERP system, we must get a basic understanding of what Scrum actually is and how it works. Scrum is a framework for team-based product development. It comes with Scrum roles, events, artifacts, and rules. The iterative approach allows you to continually create workable chunks of the final product. Thereby Scrum runs on a timebox of no more than one month with a consistent duration called sprint. Sprints produce the possibility of releasing an increment of the product at the end of the cycle.

Scrum Roles

Considering only the roles, Scrum is a straightforward methodology. It only recognizes three roles -the Scrum Master, the Product Owner, and the Development Team.

• Product Owner: The Product Owner is the most important role in Scrum. Product owners make decisions that help shape the future of the product, and without a competent Product Owner, projects will likely fail. The optimal Product Owner is usually the one who understands the requirements they’re given from their customers’ perspective best, so they should have excellent communication skills and be able to motivate others.
• Scrum Master: While the Product Owner is responsible for managing the product, the Scrum Master is responsible for managing the Scrum process, The Scrum Master’s role is limited to the Scrum process, and they do not have any technical or domain-related work to do. As the Product Owner, the Scrum Master is a leader.
• Development Team: The Development Team is responsible for taking the product requirements and turning them into a finished product. The team is self-organizing and typically takes care of impediments themselves. They are empowered and do not shift responsibility to others. If they fail, the Scrum Master helps them.

Scrum Artifacts

As for the roles, Scrum has only a few artifacts: the product backlog, sprint backlog, and product increment.

• Product Backlog: The product backlog is the product owner’s list of desired features and improvements for the product. This list can be ever-growing as there are always new ideas about how to extend and improve a product. The product owner is responsible for maintaining the product backlog, although other stakeholders, including the team, should be able to see the list and suggest new items for it.
• Sprint Backlog: The sprint backlog, which is owned by the team, contains the product backlog items that the team committed to during sprint planning, as well as any subsequent tasks and reminders. They may also add, remove or change tasks as the sprint progresses.
• Product Increment: During each sprint, the team completes a set of features or other deliverables known as the product increment. This product increment should be potentially shippable, meaning it is of high enough quality to give to users. The product owner is in charge of accepting the product increment and making sure it meets the acceptance criteria. Without a product increment, there is no possibility to inspect or make changes to the product.

Scrum Process

After summarizing the roles and artifacts, let us look into the actual Scrum process. Scrum starts with a vision. The vision might not be well-defined at first, but it will become clearer as the project moves forward. Based on this vision, the Product Owner is writing the Product Backlog, which lists out all of the tasks that are required to complete your project. At the start of each iteration, the Product Owner presents priorities from the Product Backlog to the team.

The team then decides on what it thinks it will be able to accomplish within an increment and creates a Sprint Backlog for that iteration. The team is given the responsibility to develop the features they have chosen. They take a closer look at the requirements, think about the technologies that are available, and consider their skills and how capable they are of delivering. When developing a new feature, the team brainstorms and collectively determines the approach, modifying its strategy every day to find out where the difficulties are. The team works on a shared goal and discusses how to meet it. This dialogue is the way that Scrum ensures its effectiveness.

At the end of the sprint, the team presents the new functionality to the Product Owner for review and to note down any changes that are needed. This is called the Sprint Review. Additionally, there is also the sprint retrospective, a recurring meeting at the end of every sprint in order to discuss what went well and what can be improved for the next cycle. It is important to note that the sprint review and the sprint retrospective have quite a few differences. The first one is about the product, while the second is about the team. The Sprint Review serves to maintain customer expectations, while retrospectives in the Scrum process allow teams to become faster and more compatible.

Project Overview

Enterprise Resource Planning systems are some of the world’s largest and most complex software systems. They focus on intra-company processes and they integrate functional and cross-functional business processes to make sure that similar activities and, consequently, data are managed in a consistent manner. The scope of an ERP typically includes operations, human resources, finance and accounting, sales and distribution, and procurement.

As already mentioned, we will look into the implementation of an ERP system to demonstrate how Scrum can be used to tackle complex tasks in an agile way. Specifically, our ERP implementation consists of a data warehouse, which serves as the backbone of the system, a supply chain- (SCM), and customer-relationship-management (CRM) solution and reporting functionality for the finance and accounting department. To demonstrate the Scrum process with this small ERP system, we will first look into how the planning of the project as a whole could take place when considering agile practices.

Agile ERP Development

To avoid the common pitfalls of traditional ERP development, it is advisable to employ agile practices from the get-go. This means splitting up the ERP system into individual components and the formation of cross-functional agile teams, including dedicated product owners, that implement these components. The teams can then tackle their individual tasks according to the Scrum process already described. In the case of this project, we split the development of the ERP system into four parts. Therefore we have four small teams, each working on either the data warehouse, SCM, CRM, or reporting solutions.

Scrum in Detail

After defining the overall approach to adapting an agile process to ERP development, we will look at the Scrum process in detail. Specifically, we examine how Scrum can be employed for the development of the reporting component for the accounting and finance departments.

Gathering the Team

As already explained, we can find three distinct roles inside a Scrum team. We will start with choosing a suitable product owner for our reporting software. Given that the product is used internally inside the company, the ideal product owner is the person responsible for the business process that is targeted by the developed product. In our case, the ideal product owner would be the head of the accounting and finance department. For the other components of the ERP system, we would choose the product owner according to the same criteria.

Our second team member takes on the role of the Scrum master. In the case of this project, the Scrum master will be someone from the software company developing the ERP system. Ideally, it should be a Scrum master who has done the proper training, has a Scrum certificate, and knows how to facilitate Scrum. Additionally, it is important that the Scrum master has at least a bit of domain knowledge because this ensures that the Scrum master can resolve team issues that are based on subtle domain-specific problems.

Lastly, we choose the developers for the project. Here it is not only important who but also how much. A Scrum team, excluding the Scrum master and product owner, should neither be too large nor too small. For example, smaller teams with less than three members can run into skill constraints or not enough interaction inside the team. On the other hand, a team with more than nine members can become too complex to manage. For our project, we choose seven developers so that we end up with a cross-functional team. Thereby cross-functional means that all necessary skills to develop a product are present in the team.

Vision and Product Backlog

To start the development of our reporting software, we first define the vision behind the product. The vision is an important first step because it provides a path to meet the project’s goals. The vision of the reporting software is inspired by an example of scrum.org and could look like the following table.

With the vision in mind, the product owner now writes a product backlog that contains the features that should be implemented. At this stage not all requirements are known, so this first version of the backlog is not set in stone but changes continuously throughout the development. The features in the backlog are expressed as what are called user stories. Thereby a story is a non-technical description of the feature with emphasis on the perspective of a user. The backlog is also sorted by the relevancy of the features, which means that features that are more important at the moment are placed at the top of the backlog. Following we will look at an exemplary product backlog for the reporting software:

 

As already explained, the features with higher priority are ranked at the top. In our case, the team has agreed to place the login functionality as a top priority. Following, we have data analysis and visualization, and lastly, the generation of reports and data export. In addition to the priority ranking, all stories inside the backlog need to have a workload estimation. For this project, we use story points, which are a scale describing the workload of the individual items relative to each other. This means a story with four-story points has an estimated workload that is four times greater than a story with one story point.

Sprint Planning and Sprint Backlog

With the product backlog prepared, the team is ready to start with the first sprint. On the first day of the sprint, the team meets for what is called sprint planning. Now the decision is made on which of the product backlog items are added to the sprint backlog and is ultimately implemented during the current sprint. Per definition, a sprint should add a valuable increment or, in other terms, a coherent feature to the project.

Our team decides to add the first three items of the product backlog to the sprint backlog, focusing on implementing the basic login functionality and infrastructure for the web-based application. The developers now examine the selected user stories and work out the implementation on a more technical level. An exemplary sprint backlog could look as follows:

In the course of the sprint, this sprint backlog is updated by the team members every day during the daily Scrum. The team also computes a time estimate for the work that remains for each task, which results in what is called a burndown chart.

Sprint Review and Sprint Retrospective

After completing the sprint, our team ships a working increment of the reporting software, namely a basic version supporting login and registration functionality. During the sprint review, a demonstration of the software is given, where feedback and insights are collected. Thereby, the collected feedback influences the decision of what changes should be made to the product backlog. In addition to the sprint review, the team also conducts a sprint retrospective. Here the team discusses what worked out and what was a failure regarding team performance. This event is facilitated by the Scrum master and serves to improve the team’s output further and further. For example, our team could have an outstanding performance at the daily Scrum when the remaining time for work is estimated. In contrast, there could be a lack of communication during actual work on the project. Points like this are discussed at the sprint retrospective and serve as the foundation for the team to improve.

A Comparison of Scrum and Plan-Driven

After wrapping up our exemplary scrum demonstration, we will now look at how Scrum, which is an agile approach to project management, can be compared to a plan-driven approach. The plan-driven or Waterfall approach is a traditional way to develop software and follows a sequential process. However, this methodology is plagued by a lot of drawbacks, as most of the time, a rigid plan cannot be met in software development. In contrast to the rigid process of the Waterfall approach, agile approaches like Scrum are designed to be flexible and adaptable regarding the change of requirements. Following, we will look at a detailed comparison between the two methodologies:

Conclusion

Traditional project management approaches for software development are faced with a variety of problems, given their plan-driven and inflexible nature. To combat these issues, agile project management methods like Scrum were introduced. Although agile project management approaches demand a higher degree of customer involvement, the benefits over traditional plan-driven approaches are clear, especially when faced with high-uncertainty projects.