Scrum Artifacts<\/h3>\n
As for the roles, Scrum has only a few artifacts: the product backlog, sprint backlog, and product increment.<\/p>\n
- \n
- Product Backlog:<\/strong> The product backlog is the product owner\u2019s 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.<\/li>\n
- Sprint Backlog:<\/strong> 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.<\/li>\n
- Product Increment:<\/strong> 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.<\/li>\n<\/ul>\n
Scrum Process<\/h3>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Project Overview<\/h2>\n
Enterprise Resource Planning systems are some of the world\u2019s 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.<\/p>\n
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.<\/p>\n
Agile ERP Development<\/h3>\n
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.<\/p>\n
Scrum in Detail<\/h2>\n
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.<\/p>\n
Gathering the Team<\/h3>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Vision and Product Backlog<\/h3>\n
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\u2019s goals. The vision of the reporting software is inspired by an example of scrum.org and could look like the following table.<\/p>\n
![\"\"](\"http:\/\/192.168.178.139\/wp-content\/uploads\/2023\/07\/scrum_vision.jpg\")
<\/p>\nWith 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:<\/p>\n
![\"\"](\"http:\/\/192.168.178.139\/wp-content\/uploads\/2023\/07\/scrum_product-backlog.jpg\")
<\/p>\n<\/p>\n
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.<\/p>\n
Sprint Planning and Sprint Backlog<\/h3>\n
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.<\/p>\n
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:<\/p>\n
![\"\"](\"http:\/\/192.168.178.139\/wp-content\/uploads\/2023\/07\/scrum_sprint-backlog.jpg\")
<\/p>\nIn 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.<\/p>\n
Sprint Review and Sprint Retrospective<\/h3>\n
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\u2019s 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.<\/p>\n
A Comparison of Scrum and Plan-Driven<\/h2>\n
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:<\/p>\n
![\"\"](\"http:\/\/192.168.178.139\/wp-content\/uploads\/2023\/07\/scrum_comparison.jpg\")
<\/p>\nConclusion<\/h2>\n
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.<\/p>\n
- Sprint Backlog:<\/strong> 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.<\/li>\n