INTRODUCTION

Agile software development (ASD) approaches have emerged as a viable alternative to the
traditional software development process following more than a decade of experimentation. In
addition to supporting a broad range of software development procedures as a result of their
ability to support new values, this emphasis on new values enables these techniques to support a
broad range of new values as a consequence of their ability to support new values. As a result of
the fact that traditional approaches to software development do not take into account users'
requirements throughout the whole software development process, the software requirement
management process in ASD [1] differs significantly from the traditional approach in ASD [1.
Traditional methods appear to differ from agile practices in that they appear to place a greater
emphasis on processes rather than the outcomes of those processes, according to appearances.
Several extensively used measurement methodologies in traditional methods [2] have been
impossible to be used to ASD methods [3] due to a lack of significant documentation in the field
[3, which has been previously described]. Precision measurement is required, mostly because to
the significant importance placed on approval of modification requests under ASD
methodologies; at the very least, precise cost estimation is required, which is the most critical
issue for managers throughout this process. Although there are a limited number of measurement
methods available for ASD approaches, there are numerous internationally recognized standards
and procedures for the traditional method.

A software development measurement system, on the other hand, may be used to monitor and
control the risk associated with the software development process, making it a very useful tool in
a broad variety of settings. When it comes to software development measurement, it is estimated
that the production of value adds considerably to the production of value, and that this is true.
According to the researchers, the ASD measurements were not made publicly available until the
end of 2011, and the results were not made publicly available until the end of 2012, respectively.
The COSMIC Group was the first company to use function point-based software size standards,
and they were the first in the industry when it came to ASD methodology and software sizing
recommendations, both of which were pioneered by the COSMIC Group. [3] Even if there are
presently no other studies that do so in a comprehensive manner, the goal of this study is to bring
all of the agile measuring approaches together in one place and explain them thoroughly.

OBJECTIVE

It is vital to apply metrics to industrial agile development in order to acquire a better knowledge
of the reasons for and repercussions of employing metrics in industrial agile development. It is
through the application of metrics in industrial agile development that you will obtain a deeper
knowledge of the reasons for, as well as the implications of, employing metrics in industrial agile
development. Agile teams generate their own metrics to quantify their own success, rather than
relying on measurements established by academics from outside the organization to evaluate
their own performance. Also included in this study are the repercussions of utilizing specific
performance indicators in a business setting and the ramifications of not using specific
performance indicators in a business setting.

PROBLEM STATEMENT

Due to the fact that agile teams have previously been evaluated based on performance metrics
that do not correspond to the principles of agile development, this is a mistake. When it comes to
agile methods, measurement practices are more important than they are in traditional methods,
because a lack of appropriate and effective measurement practices will increase the likelihood of
a project failing when it comes to traditional methods. It also aspires to investigate current agile
software development (ASD) methods' measurement practices, compile these practices into a
single study, and conduct a critical review of the agile versioning framework (Agile COSMIC).

PROPOSED SOLUTION

In order to establish standardized user requirements papers, which are then utilized in the
development of software, it is required for the software industry to employ effort estimate
metrics. Although there are no well-documented protocols for ASD approaches, the standards
themselves are always changing. Agile development is defined by the gradual buildup of a
backlog of user stories, which is then prioritized and executed as a series of activities as part of
the development process (US). When it comes to estimating effort in agile techniques, objective
estimation is the tactic that should be used the most often [4]. Even though this method is
straightforward to use, it delivers results that are greatly skewed in the incorrect direction,
despite the fact that it is straightforward to implement. The effort prediction must therefore be
based on actual effort from a prior iteration in order to be usable for the remaining user stories in
the current cycle. Unless this is done, it will be useless for the user stories that are still in the
pipeline for this cycle. Planning poker is a game that agile teams typically play prior to the start
of each iteration as a tool for estimating effort and establishing plans far in advance of the
beginning of the iteration. [5] As a result of the fact that everyone is involved in the estimation
process, there is no single developer that estimates for all of the clients. It is taken into
consideration when determining the final score because it is determined as the average of the
points obtained by each member of a storey. Using User Story Points to estimate the size and
complexity of software should be done with caution (USP).

The reason that this technique is more pleasant for teams and motivates them to improve their
estimating skills means that it is not deemed superior to Wideband Delphi [6, despite the fact that
it is. Agile methodologies such as Scrum, Extreme Programming (XP), and others make use of
standard software measurement approaches that have been tailored to fulfill the specific
requirements of their respective methodologies, such as the requirements of Scrum. In
accordance with Abrahamsson's most recent work on the issue [7], it is possible to estimate agile
effort with a high degree of accuracy. User tales from the past that have been kept in a database
must be reviewed in order to make predictions about what will happen in future user stories. This
is his job. When calculating effort, the model takes into account the quality and style of the user's
writing, albeit the accuracy of the model varies from one instance of the model's application to
another.

CONCLUSION

In an agile development environment, evaluating and appraising the work of software engineers
can be difficult tasks to complete. Software engineers must be more than just competent coders if
they are to be successful in agile contexts. As well as a thorough understanding of the corporate
world, these abilities are essential for success. Traditional ways of measuring the work of
software engineers do not take into consideration agile development principles and metrics. The
productivity, efficiency, social skills, mentorship, and team collaboration of software engineers
are evaluated in this study using five metrics or measurements, which are described below. For
software engineers, it is crucial to use metrics that are based on agile principles and the
manifesto when conducting performance evaluations. To optimize the software development
process, it is necessary to pay close attention to the project, the team, and the individual software
developer involved. It is also necessary to link these KPIs to the company's overall business
value. Many software firms run the risk of mixing performance management measurements with
business objectives when it comes to performance management KPIs. Example: Developers
under pressure to identify more problems during testing may unintentionally let more bugs to slip
past their fingers while writing code. We employ metrics to aid us in the achievement of our
corporate objectives. The key business objective of every agile development organization is to
deliver high-quality software on a consistent basis. Understanding the purpose is crucial for
software managers and team members if they are to place a higher priority on business objectives
and targets than metric objectives.

REFERENCES

[1] K. Beck, A. Cockburn, R. Jeffries, and J. Highsmith. (2001). Agile manifesto,

[2] M. Cohn, Agile Estimating and Planning, 1 ed.: Prentice Hall, 2005.

[3] COSMIC, "Guideline for the use of COSMIC FSM to manage Agile projects," ed, 2011.

[4] R. Moser, w. Pedrycz, and G. Succi, in Software Engieering and Knowledge Engineering
(SEKE), Boston, USA, 2007, pp. 519-522.

[5] A. Abran, Software Metrics and Software Metrology IEEE Computer Society Press, Wiley,
2010.

[6] B. Boehm, Software engieering econimics: Prentice Hall, 1981.