tracking scrum projects tools, metrics and myths about agile

8
International Journal of Emerging Technology and Advanced Engineering Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012) 97 Tracking Scrum projects Tools, Metrics and Myths About Agile Monika Agarwal 1 , Prof. Rana Majumdar 2 1 Department of Computer Science, Amity University, Noida, India 2 Department of Computer Science, Amity University, Noida, India 1 [email protected] 2 [email protected] AbstractTracking the Software during development provide a way to measure the gap between estimation of project and actual implementation of the project. It helps the tem member to modify its work practices to complete the pending task in the right direction. This Research Paper focuses on different Scrum metrics, which provide a quantitative basis for tracking the progress of the project and individual performance of team members, so that we can control the quality of the software. This research paper will discuss about some myths across agile which are widely accepted and reality behind this. KeywordsScrum metrics; Tracking Tools; Myths about Agile; Agile Metrics; Agile and CMMI; Bundown Chart; Progress Chart; Agile with Project Management tools. I. INTRODUCTION With the rapid development of the software business, in order to hurdle the incapacity of the traditional software development process in timely responding to the changes in requirements, agile development method is proposed in recent years. Agile development comprises several methodologies or frameworks, namely Scrum, XP, and Lean Software Development, Feature Driven Development, Crystal methods and others. The key feature of SCRUM lies in its iterative development strategy. In each iterative cycle called the Sprint, a chunk of the project is planned, developed, and delivered. In every Sprint, user stories within the scope of the Sprint are designed, developed, and tested. At the end of the Sprint, the set of stories that are tested and ready is delivered as a near-releasable product to the customer and the team receives early feedback from the customer. This feedback helps develop subsequent Sprints. A Sprint is completed on a set date whether or not the work is completed. If a team is unable to meet the set target at the end of a Sprint, then the team is expected to acknowledge that it did not achieve set goals. Incomplete tasks are then added to the product backlog. In this research paper, Section 2 and Section 3 discuss about the Scrum Estimation Techniques and Tracking Tools respectively, for finding out how much the actual implementation is going on different track from the estimation or planning. In Section 4, Scrum Tracking Metrics will be discussed, used to provide measurement for the software development. Section 5 briefly introduces the rumors and reality behind those in Agile Software development. II. SCRUM ESTIMATION TECHNIQUES For the successful and timely completion of any project, it is necessary to ensure that project begin with accurate estimates. While starting a Scrum project, the most difficult task is to arrive at approximate estimates. For the first little iteration, there is a gap in actual and estimated effort due to a lack of clarity about the estimation techniques. In case of Scrum, estimation transforms an individual activity to a group activity, with discussions forming an integral part of estimation. In Scrum, the estimates are created by a team who will actually be working on the project. The estimates will be accurate when they are derived from the team's domain knowledge and prior experience of working on similar tasks. Further, estimating in a discussion mode gives a global view of the task to be accomplished, such as the complexity of the task, and therefore, a better estimate. In Scrum, the effort to create a product is estimated by approximating the user stories for the product. Team member can estimate user stories using various techniques. The two most popular techniques are ideal days and story pointing.

Upload: vuongtu

Post on 30-Dec-2016

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

97

Tracking Scrum projects Tools, Metrics and Myths

About Agile Monika Agarwal

1, Prof. Rana Majumdar

2

1 Department of Computer Science, Amity University, Noida, India

2 Department of Computer Science, Amity University, Noida, India

[email protected]

[email protected]

Abstract— Tracking the Software during development

provide a way to measure the gap between estimation of

project and actual implementation of the project. It helps the

tem member to modify its work practices to complete the

pending task in the right direction. This Research Paper

focuses on different Scrum metrics, which provide a

quantitative basis for tracking the progress of the project and

individual performance of team members, so that we can

control the quality of the software. This research paper will

discuss about some myths across agile which are widely

accepted and reality behind this.

Keywords—Scrum metrics; Tracking Tools; Myths about

Agile; Agile Metrics; Agile and CMMI; Bundown Chart;

Progress Chart; Agile with Project Management tools.

I. INTRODUCTION

With the rapid development of the software business, in

order to hurdle the incapacity of the traditional software

development process in timely responding to the changes in

requirements, agile development method is proposed in

recent years. Agile development comprises several

methodologies or frameworks, namely Scrum, XP, and

Lean Software Development, Feature Driven Development,

Crystal methods and others.

The key feature of SCRUM lies in its iterative

development strategy. In each iterative cycle called the

Sprint, a chunk of the project is planned, developed, and

delivered. In every Sprint, user stories within the scope of

the Sprint are designed, developed, and tested. At the end

of the Sprint, the set of stories that are tested and ready is

delivered as a near-releasable product to the customer and

the team receives early feedback from the customer. This

feedback helps develop subsequent Sprints.

A Sprint is completed on a set date whether or not the

work is completed.

If a team is unable to meet the set target at the end of a

Sprint, then the team is expected to acknowledge that it did

not achieve set goals. Incomplete tasks are then added to

the product backlog.

In this research paper, Section 2 and Section 3 discuss

about the Scrum Estimation Techniques and Tracking

Tools respectively, for finding out how much the actual

implementation is going on different track from the

estimation or planning. In Section 4, Scrum Tracking

Metrics will be discussed, used to provide measurement for

the software development. Section 5 briefly introduces the

rumors and reality behind those in Agile Software

development.

II. SCRUM ESTIMATION TECHNIQUES

For the successful and timely completion of any project,

it is necessary to ensure that project begin with accurate

estimates. While starting a Scrum project, the most difficult

task is to arrive at approximate estimates. For the first little

iteration, there is a gap in actual and estimated effort due to

a lack of clarity about the estimation techniques.

In case of Scrum, estimation transforms an individual

activity to a group activity, with discussions forming an

integral part of estimation. In Scrum, the estimates are

created by a team who will actually be working on the

project. The estimates will be accurate when they are

derived from the team's domain knowledge and prior

experience of working on similar tasks. Further, estimating

in a discussion mode gives a global view of the task to be

accomplished, such as the complexity of the task, and

therefore, a better estimate.

In Scrum, the effort to create a product is estimated by

approximating the user stories for the product. Team

member can estimate user stories using various techniques.

The two most popular techniques are ideal days and story

pointing.

Page 2: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

98

A. The ideal day’s technique

The ideal day’s technique is an estimation technique in

which team member estimate the time to complete each

feature of a project in terms of ideal days. Here, ideal days

refer to the amount of productive time an individual puts

into a project per day. Ideal days are similar to ―number of

man days.‖ The only difference is that in ideal days, the

considerable time is for daily distractions. According to

recent studies, the maximum productive hours of

employees is around five hours irrespective of the number

of hours that they spend in the office. Therefore, an ideal

day is half of the man hours per day. Members should

remember that this value may vary for novices and

experienced employees. A novice may take more time to

complete the same task than an experienced employee.

When team member estimate a project using ideal days,

he estimate each feature by the number of ideal days and

use this effort to calculate the number of calendar days.

This calculation will take into consideration different

aspects related to the employees performing the task, such

as their experience and velocity to complete the task, and

other assumptions or dependencies on external factors. This

makes calculating the right effort complicated.

B. The story pointing technique

The story pointing technique is an estimation technique

in which the user stories are estimated by using story

points. In this, story point is a relative measure for the level

of difficulty or complexity of a feature, which is a number

in the Fibonacci sequence. If the effort to complete one

feature is twice the effort to complete another feature, then

the story points for the first feature will also be double the

story points for the second feature. For instance, if a story

having 10 story points takes 20 hours to complete, then a

story having 20 story points should take 40 hours to

complete.

The story pointing technique is based on the fact that a

task can be completed by different sets of people with

different velocities working for different numbers of hours.

Therefore, this technique focuses on the complexity of the

task rather than the number of man hours. Using the story

pointing technique for estimation enables the teams to gain

clarity on user stories and ensure that the actual and

estimated efforts are the same.

In the story pointing technique, the first step involves the

team identifying a moderately sized user story and

assigning it story points. This user story is used by

participants as a reference point to estimate other user

stories. The estimates of these user stories are then

converted to hours by using historical velocity or

productivity factors by using team velocity for calculation.

III. TRACKING TOOLS

We need continuous tracking of the project to ensure

that the team delivers the project on time. Scrum provides

various tools to track progress.

A. Burn down Charts

A burn down chart is a tool that is used to track the

progress of the project by plotting the number of days of

Sprint against the number of hours of work remaining.

Unlike other tracking charts that are used to track how

much work have been completed to date, a burn down chart

is used to track the pending work until the team's

commitment is complete.

Figure 1. Data table for plotting Burndown Charts

Figure 2. Burndown Charts based on the above data table

Page 3: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

99

The burn down chart displays the progress of the team

toward the goal.

In an ideal situation, the burn down chart is expected to

be a downward sloping graph that will hit zero on the last

day. However, this is not always the case because as the

project progresses, the team might discover unexpected

complexities or issues that may cause work to slow down,

which further leads to increased number of hours of work

remaining. If the burn down chart is not a downward

sloping graph, then it signals the team to do things

differently or increase the pace of their work. It also creates

a feedback loop and enables the teams to improve the

estimation by committing to only the amount of work that

they can accomplish in a Sprint. The teams commit usually

over or under in the first few Sprints. However, this

improves after some time and the commitments are aligned

with the work accomplished. Team Member can create a

burn down chart using a paper and pen or a whiteboard

rather than creating the chart electronically.

The data related to the hours of work remaining for each

task on a daily basis is maintained. This data is then added

to arrive at the total amount of work remaining for each

task, which is then plotted against the number of days of

Sprint to create a burn down chart. The data table and the

burn down chart for a project are shown.

B. Progress Chart

A progress chart is a tool that Scrum member use to

track the progress of the team members in accomplishing

the tasks for each Sprint, and then to get a holistic view of

the status of the tasks as not started, in-progress, and

completed for the project. In a progress chart, a whiteboard

is divided into four columns. The first column lists the

names of team members and the next three columns list the

three types of tasks. At the beginning of the project, all

tasks are written on self-stick notes along with the

estimated time and are posted in the ―Not Started‖ column.

When the team starts working on different tasks, the self-

stick notes for the tasks that the team is working on are

moved to the ―In-Progress‖ column.

The actual time that the team spends on the task is added

to the self-stick note. When a task is completed, the self-

stick note is moved to the ―Completed‖ column. If a task is

not completed in a Sprint, the self-stick note for the task is

moved to the Not Started column of the next Sprint while

retaining the history of the time spent on the task in the

previous Sprint. Members can use self-stick notes of

different colors for different columns to get a holistic view

of the tasks completed and also to track the progress of

other unplanned or add-on tasks.

This method of tracking the progress is also referred to

as the Scrum whiteboard. The progress chart is usually kept

where everybody can see it. It is deliberately manual and

primitive but highly effective and visible, because it does

not require team members to visit a website or open an

attachment to see the status. Using progress charts for

tracking a project enables Team member to:

• Compare actual versus estimates for different

tasks.

• View the time spent on unplanned tasks and how

this is affecting the Sprint.

• Check if the workload of team members is

balanced in terms of both the number of hours and tasks.

• And, get a quick and visual way to access progress

on a daily basis.

In the given example, a whiteboard is divided into three

sections, To Do, In-Progress, and done, to be used as a

progress chart. In the beginning of the project, all tasks are

detailed on self-stick notes and pasted in the To Do section.

After the project proceeds, the tasks that are in progress are

detailed by adding actual time spent and are pasted in the

In-Progress section, and the completed tasks are pasted in

the Done section. Different colored self-stick notes are used

to display tasks in different sections to facilitate easy

interpretation of the data. The progress chart for a project is

shown in Figure 3.

Page 4: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

100

Figure 3. Example of Progress Charts

C. Daily stand-up meeting

The daily standup meeting is a meeting in which the

complete team gets together for a quick status update.

These meetings are short, 15-minute meetings that are

conducted by standing in a circle. The standup meetings

should be ideally conducted at the start of working hours,

and the presence of all team members involved in the

Sprint is mandatory. In these meetings, each team member

who is a part of the Scrum is expected to summarize the

tasks that were completed on the previous day, the tasks

that are to be completed on the present-day, and any

roadblocks that the member might be facing.

The daily standup meetings enable team members to self

organize and lead to a professional and appreciative

environment. To ensure effective daily standup meetings:

Time the meetings and keep the duration of the meetings to a maximum of 15 minutes.

Ensure that the standup is a huddle rather than a meeting.

Make sure all attendees stand up during the daily standup meeting.

Signal the end after the meeting ends.

And, establish high-energy levels by discussing solutions for complicated problems offline.

IV. OVERVIEW OF TRACKING METRICS

Good metrics should enable the development of models

that are efficient of predicting process or product spectrum.

Thus, optimal metrics should be:

Simple, precisely definable—so that it is clear how the metric can be evaluated;

Objective, to the greatest extent possible;

Easily obtainable (i.e., at reasonable cost);

Valid—the metric should measure what it is intended to measure; and

Robust—relatively insensitive to (intuitively) insignificant changes in the process or product.

Page 5: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

101

A. Scrum Tracking Metrics

In Scrum, various metrics are used to track the progress

of the project and individual performance of team

members. Different metrics are used to track the Scrum

project.

1) Velocity: Velocity is a metric that is used to track

the amount of Product Backlog effort that a team

completes in a Single Sprint. Members can measure

velocity in terms of stories delivered per Sprint, story

points delivered per Sprint, or any other measure of

functionality delivered per Sprint. This measure of team productivity is used to compare performance with the benchmark or past performance and used to estimate the contents of a release or Sprint during the release or Sprint planning.

2) Standard violation: The Standard violation metric

is used to track the number of standards violated per

Sprint. The metric is used to enforce coding or design

standards. Using this metric enforces discipline within

the team regarding code quality. Therefore, this metric is

often used to direct the team towards the right behaviors

during development.

3) Business value delivered: Business value can be

measured in terms of story points, number of stories, or

an abstract measure that measures how much value the

business attaches to a feature or story. Team members can use the business value to

calculate the velocity of the team and determine the time to conclude a release. For example, when 80 percentage of the desired business value is realized, one may decide that it is enough to call it a release.

4) Defects per iteration: This metric is calculated

either as a simple count or count weighted by the

severity of defects that was introduced during a Sprint.

Because the Sprint is of a small duration, defects are

very costly in Scrum and hence should not pile up.

5) Number of stories: This metric is calculated as a

simple count or count weighted by the story complexity,

such as simple, medium, or complex, of the number of

stories in a release or a Sprint. For example, in a project

with 120 stories, the release progress can be tracked as

80 completed and accepted, 20 completed in

development but not accepted, and 20 yet to be

developed.

6) Level of automation: The level of automation in

testing is one of the key success factors of Scrum. The

ultimate aim is have automated regression tests that can

be executed in every Sprint. However, it is not a goal

that can be achieved in a day. Therefore, one should

measure how many tests are automated. For example, it

could be 200 out of 1200 tests, meaning approximately

16 percentage automation.

7) Number of tests: A measure of the number of tests

that have been developed, executed, and passed to

validate a story, epic, or the entire release.

V. MYTHS ABOUT AGILE

A. Common Myths And Reality

Myths are widely accepted but mistaken beliefs. There

are some myths about Agile:

Requires no documentation and works informally on trust.

Requires mature teams that are co-located.

Allows no time for designing.

Cannot work with CMMI or other process models.

But the reality is different:

Agile requires just enough documentation.

Co-located, mature teams help in communication, but are not a prerequisite.

Agile requires iterative, incremental design and not an all-encompassing rigid design.

Most CMMI level 5 and ISO certified teams use the agile methodology.

As there is a myth about agile is that agile is a

standalone project management tool. As the traditional

software developer wants to use their experience with

existing project tool, in this research paper, we combine the

agile Approach with existing Project tool.

B. Agile with Existing Project Management tools

1) Agile and CMMI: Software projects are often

executed at CMMI level 5 and use the Lean

development process for optimization. These projects

are complex and comprehensive. Customers require

faster, cost-effective delivery with flexibility for change.

Managing complexity requires process discipline and

handling change requires adaptability. While CMMI

provides discipline with its 25 defined process areas and

their own goals, expected practices, and recommended

sub practices, Agile methodology enhances adaptability

with its iterative development principle.

Page 6: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

102

CMMI improves the ability to deliver on the agreed

upon schedule, cost, and quality, whereas frequent

deliverables in Agile make it possible for the users to

hone their requirements. CMMI provides a general guideline about what to do

but not how to do it. Agile methodology provides a specific how-to implementation model. Therefore, combining agile practices with CMMI brings out a more powerful combination than either one alone. When Agile is implemented in an appropriate environment, it may address CMMI level 2 and level 3 practices. Most CMMI process areas relating to project management are addressed by Scrum and areas related to software engineering are addressed by XP. When CMMI processes are optimized using Scrum in large projects, productivity increases and rework decreases. CMMI provides insight into the processes required to maintain discipline, and Scrum provides guidance for efficient management that allows high flexibility and adaptability.

2) Agile and PMBOK: The Project Management

Body of Knowledge (PMBOK) is a process-based

approach to manage most projects. PMBOK is a process

framework similar to CMMI and is not a methodology

like Agile. The PMBOK recognizes 44 processes that

fall into five process groups: initiate, plan, execute,

monitor and control, and close. These five process

groups have nine knowledge areas. All the Agile

practices can be mapped to one of the 44 processes in

the PMBOK. Studies prove that 23 of the 44 processes in the

PMBOK have no matching practice in Agile. Some of these 23 processes are in the Planning, Monitoring and Controlling, and Closing phase. Agile methodology does not have explicit guidance for budgeting, risk planning, and procurement processes in the Planning phase, and has weak documentation plans. In the Monitoring and Controlling phase, Agile allows uncontrolled change in the design. In the Closure phase, the iteration closures do not include archiving of administrative and technical data, and not much attention is paid to project closuras.

Adding some of these processes, such as risk planning, activity planning, budgeting, controlling requirements change, archiving while closing iterations, and project closure activities, allows Agile to work hand-in-hand with PMBOK without compromising the agility of the project. Therefore, Agile does not replace the traditional project management methods, but supplements them by providing a powerful methodology to manage the execution of projects.

3) Micro- Management with agile: One of the myths

in Agile is that some of the Scrum practices, such as

reporting during daily meetings, active participation of

Product Owner and management, review meetings with

demos, and frequent retrospective meetings lead to

micro-management. Indeed this feedback is common

from new Scrum Teams. Scrum practices include:

Reporting daily meetings

Active product owner and management participation

Review meetings with demos

Retrospective meetings

However, in true Scrum implementation, it is the team that self-manages its day-to-day activities, and management focuses on the release content or the iteration level. To overcome any micro-management, the Scrum Master must take on a facilitator role and not a taskmaster role. The daily meetings should be used to synchronize the teams and identify impediments and not to collect the project status. Therefore, time should be spent on future actions to bring out dependencies, issues, and communication between the team members. The daily meetings should be well organized and prompt but not hurried.

VI. SUMMARIZATION AND CONCLUSION

Proper Estimation helps us to fill the gap in the

estimated and actual time taken. This gap can be generated

due to lack of the proper tracking of tasks and problems

with smooth communication among team members. In

order to avoid these issues in subsequent iterations, this

research paper discussed about specific tools and

techniques to estimate and track project and ensure

effective communication. Accurate estimation and tracking

helps the team modify its work practices to update the

pending tasks, and effective communication helps the team

ensure that it is working in the right direction.

Many of the challenges for Agile are also present in

traditional methodologies. However, Scrum will make

them visible early in the project. Early visibility of

problems is good from a management view point because

team member can take appropriate corrective actions.

In this research paper, we discussed about the myths in

agile development and explore the reality based on work

practices of Agile Software Developer. Further, the agile

implementation is experienced with traditional project

management tools.

Page 7: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

103

VII. FUTURE SCOPE

The Scrum methodology comprises many Sprints, and

the team has to estimate each backlog item so that the

Sprint Backlog can be identified. Accurate estimation is a

challenge for first-time users of this methodology. Teams

tend to underestimate each backlog item. In such cases,

managers tend to interfere and help with the estimates.

Sometimes, the user stories are not detailed enough to

estimate.

The Scrum methodology treats every team member

equally and focuses exclusively on team goals and team

achievements. The hierarchy between a manager and team

member is effectively removed, which may disturb

experienced members from a traditional management

approach. The experienced members may:

Feel slighted or demoted.

Find their experience undervalued.

Find no opportunity to ―differentiate‖ themselves from the rest of the team.

Find Scrum restrictive, thus preventing them from experimenting and learning.

Or, feel the absence of the ―growth path.‖

Following the Agile methodology and scaling Scrum for

large projects are a challenge because products are

delivered frequently by different teams working in different

areas of the same large project. Teams face integration and

overlap issues. Scaling agile is not simple. The complexity

increases not in proportion to the size of the team but at the

square of the size of the team. That means a 20 member

team project will be 4 times as complex as a 10 member

team.

References

[1] Schwaber, Ken and Mike Beedle. Agile software Development with

Scrum. Prentice Hall, 2002.

[2] Sutherland, Jeff. ―Inventing and Reinventing Scrum in five companies‖, 21 September 2001.

[3] R.L. Glass, ―Inspections—Some Surprising Findings,‖ Comm.ACM, vol. 42, no. 4, pp. 17-19, Apr. 1999

[4] SEI Supporting Tool web site, http://www.sei.cmu.edu/tsp/tools/studypsp-form.cfm

[5] A. Cockburn and J. Highsmith, ―Agile Software Development: The People Factor,‖ Computer, Nov.2001, pp. 131-133.

[6] [Suphak Suwanya and Werasak Kurutach ―Applying Agility Framework in Small and Medium Enterprises‖ ASEA 2009, CCIS 59, pp. 102–110, 2009 Springer-Verlag Berlin Heidelberg 2009

[7] Entry SCRUM in Wiki website. http://en.wikipedia.org/wiki/Scrum_(development)

[8] Hillel Glazer, Jeff Dalton, David Anderson, David J. Mike Konrad,Sandy Shrum, ―CMMI® or Agile:Why Not Embrace Both‖ TECHNICAL NOTE, CMU/SEI-2008-TN-003.

[9] He Huang, Peiji Tao, Xianming, Liu, Qiang Cui ―Research and Practice of Reducing and Merging XP with Heavy Soft ware Developing Process‖ Journal of Computer Engineering and Applications 2003.22

[10] Hui Li, Peiji Tao, Wenfeng Li ― Combining XP and RUP to develop small projects‖ Computer Engineering & Design 2005

[11] Tom Demarco ―Software Engineering: An Idea Whose Time Has Come and Gone?‖ IEEE Software, July/August 2009, pp95-96

[12] www.mountaingoatsoftare.com/scrum/

[13] Turk, D., France, R., Rumpe, B. ―Agile SoftwareProcesses: Principles, Assumptions and Limitations.‖ Technical Report.Colorado State University, 2002.

[14] Watts S. Humphrey PSP: A Self-Improvement Process for Software Engineers Addison-Wesley, 2005

[15] LanCao; Mohan, K; PengXu; Ramesh, B.―How extreme does extreme programming have to be? Adapting XP practices to large-scale projects‖Proceedings of the 37th Annual Hawaii International Conference onSystem Sciences, 2004.

[16] He Huang, Peiji Tao, Xianming, Liu, Qiang Cui ―Research and Practice of Reducing and Merging XP with Heavy Soft ware Developing Process‖ Journal of Computer Engineering and Applications 2003.22

[17] www.controlchaos.com/scrumwp.html

[18] Tobias Mayer ―The Essence of SCRUM‖ http://agilethinking.net/essence-of-scrum.html

[19] http://agilealliance.com/articles/articles/InventingScrum.pdf

[20] A.F. Ackerman, L.S. Buchwald, and F.H. Lewski, ―SoftwareInspections: An Effective Verification Process,‖ IEEE Software,vol. 6, no. 3, pp. 31-36, May/June 1989.

[21] Turk, Dan; France, Robert; &Rumpe, Bernhard. (2002). ―Limitations of Agile Software Processes.‖ Proceedings of the Third International Conference on eXtreme Programming and Agile Processes in Software Engineering, p. 43-46, May 26-29, 2002, Alghero, Sardinia, ITALY.

[22] J Wäyrynen, M Bodén, G Boström ―Security Engineering and eXtreme Programming: an Impossible marriage?‖Extreme Programming and Agile Methods - XP/Agile Universe 2004Springer Berlin / Heidelberg

[23] Barry Boehm Richard Turner Balancing agility and discipline: a guide for the perplexed Addison-Wesley, 2004

[24] Cockburn, A. Agile Software Development.Bostom:Addison-Wesley 2002

[25] Chris F. Kemerer, Mark C. Paulk, ―The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data‖, IEEE transactions on software engineering, 2009 Vol 35 no.4

[26] Extreme Chaos, The Standish Group International, 2001.

[27] G. Eason, B. Noble, and I. N. Sneddon, ―On certain integrals of Lips Software Metrics SEI Curriculum Module, SEI-CM-12-1.1, December 1988

[28] ―Software Quality Metrics for Object Oriented System Environments‖, June 1995, National Aeronautics and Space Administration, Goddard Space Flight Center, Greenbelt Maryland

Page 8: Tracking Scrum projects Tools, Metrics and Myths about Agile

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)

104

[29] Tu Honglei1, Sun Wei1, Zhang Yanan1, ―The Research on Software Metrics and Software Complexity Metrics‖, International Forum on Computer Science-Technology and Applications, 2009.

[30] http://www.pearsonhighered.com/samplechapter/0201729156.pdf.

[31] www.agilescrum.com/

ACKNOWLEDGMENT

I would like to thank Professor Rana Majumdar all the help he

offered in the course of my studies. His encouragement and

guidance have been of great value to me Personally, I would also

like to thank my parents and my partner for their support in my

studies.

AUTHORS PROFILE

1Ms. Monika Agarwal is Software Engineer in the NIIT

Technology. Her Research activities are based on Agile Software

Development in Distributed Environment. She is pursuing her

M.Tech in Computer Science and Engineering from Amity

University, Noida.

2Mr. Rana Majumdar is working as Assistant Professor in

Department of Computer Science and Engineering in Amity

University Noida, UP, INDIA. His Research area includes Agile

Methodologies. He is pursuing his Ph.D in Computer Science and

Engineering from Amity University.