Designing an Integrated Public Complaint System regarding Public

Services using the Scrum Method

Fajar Ratnawati and M. Asep Subandri

Rekayasa Perangkat Lunak, Politeknik Negeri Bengkalis, Bengkalis, Riau, Indonesia

Keywords: Scrum Method, OPD, Integrated System, Public Service.

Abstract: One form of accountability of the government of a region to the community is to provide the maximum

possible service. However, due to various factors, the services provided sometimes have shortcomings. Of

course, with many Regional Apparatus Organizations (OPD) providing services, the leaders of the region

cannot supervise them one by one. People who interact directly with OPD and find something that is wrong

can provide criticism, suggestions, or complaints. However, not infrequently the complaint becomes a mere

passing wind, the complaint is not responded to by the OPD concerned. Apart from feeling lazy to not get a

response, people also often complain that they don't know where to complain, then they don't know how to

make a complaint. The location of the community which is far from the OPD which is in the city center also

discourages the community from complaining about public services that are not optimal. Based on these

problems, the authors propose the design of an integrated public complaint system. This system will be

designed with one of the well-known models in the agile software development method, namely Scrum. The

stages of scrum activities include product backlog, sprint backlog, daily scrum, sprint review, and sprint

retrospective. Roles in Scrum include product owner, scrum master, and development team. Scrum has

structured and iterative stages, so that if the product in the first sprint is not sufficient to meet the needs, then

in the next sprint a system can be developed according to user evaluation. The results of this design are

expected to help develop / implement the design into a complete system that is in accordance with the wishes

of the user.

1 INTRODUCTION

The development of technology is currently growing

rapidly. The community is very familiar and familiar

with the existence of information and communication

technology (ICT). They already rely on ICT in their

daily activities, be it for shopping activities, social

activities, or for activities within the government.

In Indonesia, the quality of public services

provided by the government is still not optimal. In the

aspect of implementing public services, the

community as users of public services has the right to

provide suggestions or complaints, criticisms or

complaints about service problems that occur.

Meanwhile, the government must respond to every

complaint submitted by the community and provide

solutions to problems submitted by the community.

Public complaints are important for the

government to see how successful it is in carrying out

an activity in this case services, as well as looking for

shortcomings from these activities, as evaluation

material to improve the quality of services provided.

Where, the better the quality of public services will

encourage the advancement of a region.

The problem is the low response of service

providers, resulting in the emergence of skepticism in

the community. People seem to be deterred from

making complaints. Indeed, the number of complaints

in several public service agencies is relatively low.

However, the low number of complaints does not

actually describe the community's satisfaction with

public services, on the contrary precisely because

people feel unsure of the results that will be obtained

by making complaints.

Another reason for the lack of public participation

in complaining about a public service is that

complaints must be submitted directly to the public

service unit and the apparatus, then the public does

not understand which government agencies receive

and follow up on complaints, the public does not

know how to submit complaints, and the complaint

procedure is lengthy. complicated and difficult to

398

Ratnawati, F. and Subandri, M.

Designing an Integrated Public Complaint System regarding Public Services using the Scrum Method.

DOI: 10.5220/0010946500003260

In Proceedings of the 4th International Conference on Applied Science and Technology on Engineering Science (iCAST-ES 2021), pages 398-405

ISBN: 978-989-758-615-6; ISSN: 2975-8246

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

make people reluctant to complain about problems

related to public services.

Bengkalis is one of the districts in Riau Province.

Bengkalis Regency consists of 11 districts. Its

territory includes the mainland of the eastern part of

the island of Sumatra and the archipelago. The

position of the capital city of Bengkalis Regency,

which is on Bengkalis Island, makes it difficult for

people from the coastal areas of Sumatra and other

islands to complain about public services. For this

reason, it would be nice if the Bengkalis Regency

Government had a service media that could be

accessed via the internet so that its people could

inform or complain about problems in city

development or government problems and problems

related to inadequate public facilities easily without

having to go to the government office.

Based on this thought, the author proposes a

public complaint system related to integrated public

services, an online service to accommodate

aspirations, complaints and information from the

public regarding public services or an incident that

occurred in the Bengkalis Regency area. The

community can convey the problems they encounter

through this system. The complaint will be followed

up by the Regional Apparatus Organization (OPD)

that provides services. In order to guard the OPD so

that they are willing to follow up on complaints, this

system will be monitored directly by regional leaders,

namely the Regent, Deputy Regent and Regional

Secretary. This complaint system will be maintained

and managed by the Bengkalis Regency

Communication and Information Office

(Diskominfo), which is its main task force.

There are two methods that are widely used by

most system developers, namely Traditional Software

Development and Agile Software Development. In

this study, the authors chose to design the system

using one of the models in the Agile Software

Development method, namely Scrum. Scrum is

considered to be able to produce good quality

application programs or in accordance with the

wishes of the user because it gets feedback on an

ongoing basis, with the condition of the development

team being limited.

2 RELATED WORK

The research conducted by Sandi et al with the title

"Implementation of E-Government Through Service

Applications "Apekesah" in Batam City" with the aim

of knowing the implementation of e-government in

the city of Batam which refers to the indicators of the

e-government component Indrajit (2005) and the

results of this study is that all indicators of the

implementation of E-government by the Batam City

Communication and Information Office have not

been fulfilled, namely content development,

competency building and citizen interface.

Furthermore, the research conducted by Siti

Widharetno Mursalim with the title Complaint

Management Analysis of the People's Online

Complaints Aspiration Service System (Lapor) in the

City of Bandung. Researchers studied and analyzed

the management of public complaints in the city of

Bandung. It uses qualitative research methods. By

using a complaint management theory based on

Tjiptono's theory, namely: Commitment, Visible,

Accessible, Simplicity, Speed, Fairness,

Confidential, Records, Resources and Remedy, he

concludes that the People's Online Complaints

Aspiration Service (LAPOR!) can facilitate the public

in the city of Bandung make complaints, express

aspirations, or complaints against the performance of

the Bandung city government.

The same research was also conducted by Dimas

Ramdhana Prasetya et al. Researchers analyzed the

management of public complaints in Malang City

who have used the application. The research focuses

on assessing how the management of public

complaints is carried out by the Malang City

Communication and Information Office, then what

are the supporting and inhibiting factors of the

management of public complaints carried out by the

Malang City Communication and Information Office.

With the application that can be accessed via the

internet, the researcher concludes that public

complaints can be easily conveyed, but the

bureaucracy is too complicated and there are no

information officers hampering the complaint process.

Text mining applications for automatic clustering

of public complaints are increasing in the city of

Semarang. By using the K-means algorithm, research

from Afida et al succeeded in clustering complaint data

with good results. This is obtained from the purity

value where the value is 1 for each existing cluster.

Lydia Liliana in her research proposed an

information system, let's report in order to reach the

2030 Sustainable Development Goals or SDGs.

Taking a case study in the Cengkareng Timur sub-

district, she found that in general, when people have

complaints, they have to go directly to the RT/RW,

but these complaints have not of course delivered not

even handled quickly. The “Yuk Lapor” application

proposed by the researcher is intended to convey

aspirations/complaints about problems in their

environment. The method used in designing the

Designing an Integrated Public Complaint System regarding Public Services using the Scrum Method

399

application is the System Development Life Cycle

(SDLC), but unfortunately it is only at the design

stage of the application description.

3 METHOD

In this study, the system design was carried out using

an agile method with the Scrum model. Scrum is a

software engineering model that uses Agile

principles, which refers to the strength of team

collaboration, incremental products and iterative

processes to achieve goals/products. Scrum is a

framework that uses various processes and

techniques. Scrum reduces the ineffectiveness of

product management and work techniques so as to

improve product, team, and work environment

performance. Figure 1 below illustrates the process

steps of the scrum model:

Figure 1: Stages in the Scrum model.

1) The Scrum Master

The Scrum Master is the person who makes the

Scrum group work effectively and the Scrum progress

always goes well until it reaches the desired goals or

objectives if there is an obstacle in the work process,

the Scrum master acts as an intermediary then

provides solutions and decides the solutions that will

be used to solve existing problems.

2) The Product Owner

The Product Owner is the person responsible for

ensuring that the Scrum team produces a product that

can be presented in front of the client.

3) The Product Backlog

The Product Backlog is a list of user wishes in the

form of expectations when this project has been

completed, here also we can continue to monitor

whether the projects we make are in accordance with

the wishes of the user or not.

4) The Sprint Backlog

The Sprint Backlog is the result of slices / fragments

of the Product Backlog where we think what we

should develop, which must be completed first and

how to do it so that the project is achieved according

to the wishes of the users in the Product Backlog.

5) User Story

User Story is the result of interviews with users which

is then documented from the needs of our software

used in agile methods, one of the advantages of user

stories is that it is easy to adapt according to software

needs, and also user stories are described in a very

natural language. so that people who do not have an

IT background can understand the software being

developed. User stories are input from users,

customers, teams and stakeholders

4 RESULT AND DISCUSSION

The results of this study are in accordance with the

steps of the method used, namely Scrum which begins

with making user stories obtained from input from the

community, OPD, teams and stakeholders; product

backlog which is the result of user stories; sprint

backlog consisting of the sprint process, daily scrum,

sprint review, and sprint retrospective. Figure 2

shows an overview of the user story about the system

design according to the user. There are 4 users in this

system, namely the community, discominfo, OPD

and regional leaders.

Figure 2: User story.

Based on the information obtained from Figure 2, the

following is the design of an integrated public

iCAST-ES 2021 - International Conference on Applied Science and Technology on Engineering Science

400

complaint system related to public services using the

Scrum method.

4.1 Product Backlog

At this stage of creating a product backlog, the

backlog feature is determined based on the priority of

the product owner. Priority determination can be seen

in Figure 3.

Figure 3: Product backlog.

From the description of the product backlog above, a

table is made to see a more detailed product backlog

consisting of:

− ID, is the number or unique identity of each

product backlog item

− Product backlog item, is a brief description of

the task

− Priority, is the priority level of the product

backlog item

− Initial estimate, is the estimated processing time

for each product backlog item

Table 1: Product Backlog.

Product Backlog

Items

Priority

Initial

Estimate

1 Creating admin

dashboard templates

High 3

2 Create complaint

category data

mana

ement

High 2

3 Create OPD data

management

High 2

Sprint 1 7

4 Create android

application design

Medium 7

5 Creating citizen

registration features

Medium 2

Sprint 2 9

6 Create a public

complaint feature

low 4

7 Create a chat feature

between the

community and

OPD

low 4

8 Create forum

features

low 5

9 Create a feature to

send a warning from

the leadership to the

OPD

Low 2

Sprint 3 15

10 Web admin

implementation

11 Android application

implementation

12 OPD web

implementation

13 Leader web

implementation

Future sprint

4.2 Sprint Backlog

The sprint backlog is the result of the sprint planning

carried out at the beginning of the sprint to plan the

work to be done in the sprint. At the sprint stage, it is

determined based on the product backlog table. In this

study, the resulting sprints were 4 sprints based on the

priority of each product backlog with a sprint duration

of 31 days.

4.2.1 Sprint 1

Sprint 1 consists of 3 product backlog items that will

be done by 3 developers. Sprint 1 is focused on web

design. Product backlog items in sprint 1 include

creating admin dashboard templates, making

complaint category data management, creating

OPD data management. More details can be seen in

table 2.

In sprint 1 the work estimate at the beginning of

the print uses the default focus factor value, which is

70% because there is no previous reference, then the

Designing an Integrated Public Complaint System regarding Public Services using the Scrum Method

401

Table 2: Sprint backlog on sprint 1.

ID Backlog Items Status

Estimated

days

Creating admin

dashboard tem

lates

Complete 3

Create complaint

category data

mana

ement

Complete 2

Create OPD data

mana

ement

Complete 2

calculation of work capacity and estimated

processing time is as follows:

Work capacity = estimated days / focus factor

= 7 / 0.7

= 10

Estimated processing time = work capacity / team

= 10 / 3

= 3.3

From the above calculation, the estimated time for

sprint 1 is rounded up from 3.3 to 3 days.

The development process in sprint 1 experienced

an extension of time from the initial estimate of 3 days

to 10 working days. The actual number of working

days for the team is 30 working days. The extension

of the sprint time on the implementation of sprint 1 is

due to the estimated days not running out or not being

completed in accordance with the estimated planning

time. Because sprint 1 is the start of the team carrying

out the sprint, the sprint execution time is added until

the estimated days are up to find out the team's focus

factor value which will be used to calculate the

estimated time for the next sprint. The value of the

focus factor with an estimated 7 days and a work

capacity of 30 days is 0.23 or 23%.

4.2.2 Sprint 2

Sprint 2 consists of 3 developers who will work on

the system design. Sprint 2 will work on the sprint

backlog with medium priority. In sprint 2, the target

for achieving the sprint is to design an application to

submit complaints to the public, as well as login and

days in sprint 2 is 9 days. For sprint 2 can be seen in

table 3.

Table 3: Sprint backlog on sprint 2.

ID Backlog Items Status

Estimated

Create android

application design

Complete 7

Creating citizen login

and re

istration features

Complete 2

In sprint 2 the work estimate is obtained from the

focus factor obtained from sprint 1, which is 0.23. By

knowing the estimated days and the focus factor, the

ideal work capacity is 39.13 rounded up to 39 days.

To find out the estimated working time, the ideal

work capacity value is divided by the developer team,

so 13 is produced so that the estimated processing

time for sprint 2 is 13 days.

The development process in sprint 2 is faster than

the initial estimate of 13 days to 10 working days. The

actual number of working days for the team is 30

working days. So the value of the focus factor

obtained with an estimated 9 days and a 30 day work

capacity is 0.30 or 30%.

4.2.3 Sprint 3

Sprint 3 consists of 3 developers who will work on

the system design. Sprint 3 will work on a low priority

sprint backlog which consists of making a public

complaint feature and creating a chat feature between

the community and OPD. The goal to be achieved

from Sprint 3 is to design the appearance of the public

complaint feature and the chat feature. Estimated

days on sprint 3 is 15 days. For sprint 3 can be seen

in table 4.

Table 4: Sprint backlog on sprint 3.

ID Backlog Items Status

Estimated

days

Create a public

complaint feature

Complete 4

Create a chat feature

between the community

and OPD

Complete 4

8 Create forum features Complete 5

Create a feature to send

a warning from the

leadershi

to the OPD

Complete 2

In sprint 3 the work estimate is obtained from the

focus factor obtained from sprint 2, which is 0.30. By

knowing the estimated days and the focus factor, the

ideal work capacity is 50 days. To find out the

estimated working time, the ideal work capacity value

is divided by the developer team, so the result is

16.67. So the estimated processing time for sprint 3 is

rounded up from 16.67 to 17 days.

The development process in sprint 3 is faster than

the initial estimate of 17 days to 10 working days. The

actual number of working days for the team is 30

working days. So the value of the focus factor

iCAST-ES 2021 - International Conference on Applied Science and Technology on Engineering Science

402

obtained with an estimated 15 days and a 30 day work

capacity is 0.50 or 50%.

4.3 Daily Scrum

Daily scrum is an activity with a time limit of 10

minutes every day so the team can synchronize work

and plan what to do the next day by updating the

burndown chart. The following is the result of the

burndown chart from sprint 1 to sprint 3.

Figure 4: Burndown Chart Sprint 1.

Figure 4 shows the first day of the sprint which is July

5, 2021, the team estimates that there are about 7

estimated days based on team speed. Sprint 1 with an

estimated number of 7 days and a 10 day sprint

execution time. At the start of sprint 1, the actual task

day remaining line decreases further and is above the

ideal task remaining line. This shows that the

implementation is not in accordance with the

estimated time that has been planned.

Figure 5: Burndown Chart Sprint 2.

The actual task days remaining line on the burndown

chart sprint 2 chart at the start may or may not be far

from the ideal task remaining line, this indicates the

implementation and planning as planned. It is

different from what happened on the 3rd to 10th work

days, the actual task day remaining is below the ideal

task remaining line. This condition indicates that the

sprint will be completed earlier than the estimated

time previously set.

Figure 6: Burndown Chart Sprint 3.

The actual task days remaining line on the burndown

chart sprint 3 chart at the start may or may not be far

from the ideal task remaining line, this indicates the

implementation and planning as planned. It is

different from what happened on the 4th to 10th work

days, the actual task day remaining is below the ideal

task remaining line. This condition indicates that the

sprint will be completed earlier than the estimated

time previously set.

4.4 Sprint Review

The system demo is done with a direct tutorial using

a system design application, namely adobeXD. After

the demo tutorial is done, the user provides a review

and input on the system design that has been

implemented.

The results of the review and input from users will

be carried out in the next sprint before being further

developed so that it can actually be used by the user.

The results of the system design are as follows:

Figure 7: Register.

1234567

Burndown Chart Sprint 1

actual task day remaining ideal task remaining

012345678910111213

Burndown Chart Sprint 2

Sprint 2 actual task day rem aining Sprint 2 ideal task remaining

Designing an Integrated Public Complaint System regarding Public Services using the Scrum Method

403

Figure 8: Login.

Figure 9: Account.

Figure 10: Home.

Figure 11: Make a complaint.

Figure 12: Complaint status.

Figure 13: Forum.

Figure 14: Forum contents.

iCAST-ES 2021 - International Conference on Applied Science and Technology on Engineering Science

404

Figure 15: Message.

Figure 16: Message content.

4.3 Sprint Retrospective

On This phase is carried out by holding a meeting to

evaluate the team's performance for one sprint with a

maximum time duration of 3 hours. This is done to

make plans regarding performance improvements

that will be carried out in the next sprint

5 CONCLUSIONS

Based on the results of the application of the Scrum

method in the design of an integrated public

complaint system related to public services, it can be

concluded as follows:

1. The number of sprints produced is 4 sprints with

the focus factor of each sprint (does’n include

future sprints) increasing.

2. The scrum method can be applied to mid-scale

systems with a limited number of development

teams

3. The scrum method can overcome changing

requirements from user evaluation results

4. For the next research stage, a future sprint is

carried out so that it becomes a complete system

that is in accordance with user needs and can be

used by the community.

REFERENCES

Afida, Dita, Erika Devi Udayanti, dan Etika

Kartikadharma. 2021. Aplikasi Text Mining untuk

Klasterisasi Aduan Masyarakat Kota Semarang

Menggunakan Algoritma K-means. Jurnal

Transformatika Vol 18 No 2 Hal 215-224.

Liliana, Lidya. 2020. Yuk Lapor : Sistem Informasi

Pengaduan Keluhan Masyarakat Berbasis Aplikasi

Mobile untuk Inovasi Teknologi Pembangunan

Berkelanjutan. Journal of Business and Audit

Information Systems Vol 3 No 2.

Mursalim, Siti Wedharetno. 2018. Analisis Manajemen

Pengaduan Sistem Layanan Aspirasi Pengaduan Online

Rakyat (Lapor) di Kota Bandung. Jurnal Ilmu

Administrasi Vol 15 No 1.

Prasetya, Dimas Ramdhana, Tjahjanulin Domai, dan Lely

Indah Mindarti. 2013. Analisis Pengelolaan Pengaduan

Masyarakat Dalam Rangka Pelayanan Publik. Jurnal

Administrasi Publik Vol 2 No 1 Hal 1151-1158.

Rohmatun, Siti, Ida Widihastuti, dan Muhammad

Khosyi’in. 2017. Pengembangan Sistem Informasi

Pengaduan Masyarakat Kabupaten Jepara Berbasis

Web. Jurnal Transistor Elektro dan Informatika Vol 2

No 2 Hal 111-123.

Sandi, Rio Pratama, Nazaki, dan Nur Aslamaturrahmah

Dwi Putri. Pelaksanaan E-Government Melalui

Aplikasi Layanan “Apekesah”di Kota Batam.

Universitas Maritim Raja Ali Haji.

Suharso, Wildan, Bayu Indra Wicaksono, dan Gita Indah

Marthasari. 2018. Penerapan Scrum dan Algoritma

COCOMO Pada Aplikasi Manajemen Proyek

Perangkat Lunak. Jurnal Sains dan Teknologi Informasi

Vol 4 No 1.

Designing an Integrated Public Complaint System regarding Public Services using the Scrum Method

405