IJETAE_0312_16

7/28/2019 IJETAE_0312_16

1/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 AgileMonika Agarwal 1, Prof. Rana Majumdar2

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

[email protected]

[email protected]

Abstract

Tracking the Software during developmentprovide 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. INTRODUCTIONWith 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 endof 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 aSprint, 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 TECHNIQUESFor 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 priorexperience 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.

7/28/2019 IJETAE_0312_16

2/8



98

A. The ideal days techniqueThe ideal days 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 tocomplete 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 techniqueThe story pointing technique is an estimation technique

in which the user stories are estimated by using storypoints. 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 orproductivity factors by using team velocity for calculation.

III. TRACKING TOOLSWe 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 ChartsA 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 chartis 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

7/28/2019 IJETAE_0312_16

3/8



99

The burn down chart displays the progress of the teamtoward 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 usuallyover 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 ChartA 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 andprimitive 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 threesections, 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.

7/28/2019 IJETAE_0312_16

4/8



100

Figure 3. Example of Progress Charts

C.Daily stand-up meetingThe 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 selforganize and lead to a professional and appreciative

environment. To ensure effective daily standup meetings:

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

Ensure that the standup is a huddle rather than ameeting.

Make sure all attendees stand up during the dailystandup meeting.

Signal the end after the meeting ends. And, establish high-energy levels by discussing

solutions for complicated problems offline.

IV. OVERVIEW OF TRACKING METRICSGood metrics should enable the development of models

that are efficient of predicting process or product spectrum.

Thus, optimal metrics should be:

Simple, precisely definableso that it is clear howthe metric can be evaluated;

Objective, to the greatest extent possible; Easily obtainable (i.e., at reasonable cost); Validthe metric should measure what it is

intended to measure; and

Robustrelatively insensitive to (intuitively)insignificant changes in the process or product.

7/28/2019 IJETAE_0312_16

5/8



101

A. Scrum Tracking MetricsIn 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 trackthe 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 Sprintduring the release or Sprint planning.

2) Standard violation: The Standard violation metricis 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 bemeasured 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 tocalculate the velocity of the team and determine the timeto conclude a release. For example, when 80 percentageof the desired business value is realized, one may decidethat it is enough to call it a release.

4)Defects per iteration: This metric is calculatedeither 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 asimple 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 projectwith 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 intesting 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 teststhat have been developed, executed, and passed to

validate a story, epic, or the entire release.

V. MYTHS ABOUT AGILEA. Common Myths And Reality

Myths are widely accepted but mistaken beliefs. There

are some myths about Agile:

Requires no documentation and works informallyon 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 theagile 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 tools1)Agile and CMMI: Software projects are oftenexecuted at CMMI level 5 and use the Leandevelopment 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.

7/28/2019 IJETAE_0312_16

6/8



102

CMMI improves the ability to deliver on the agreedupon 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 aspecific how-to implementation model. Therefore,combining agile practices with CMMI brings out a morepowerful combination than either one alone. WhenAgile is implemented in an appropriate environment, itmay address CMMI level 2 and level 3 practices. MostCMMI process areas relating to project management areaddressed by Scrum and areas related to softwareengineering are addressed by XP. When CMMIprocesses are optimized using Scrum in large projects,productivity increases and rework decreases. CMMIprovides insight into the processes required to maintaindiscipline, and Scrum provides guidance for efficientmanagement that allows high flexibility andadaptability.

2)Agile and PMBOK: The Project ManagementBody 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 Agilepractices 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 ofthese 23 processes are in the Planning, Monitoring andControlling, and Closing phase. Agile methodology doesnot have explicit guidance for budgeting, risk planning,and procurement processes in the Planning phase, andhas weak documentation plans. In the Monitoring andControlling phase, Agile allows uncontrolled change inthe design. In the Closure phase, the iteration closuresdo not include archiving of administrative and technicaldata, and not much attention is paid to project closuras.

Adding some of these processes, such as riskplanning, activity planning, budgeting, controllingrequirements change, archiving while closing iterations,and project closure activities, allows Agile to workhand-in-hand with PMBOK without compromising theagility of the project. Therefore, Agile does not replacethe traditional project management methods, butsupplements them by providing a powerful methodologyto manage the execution of projects.

3)Micro- Management with agile: One of the mythsin 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 theteam that self-manages its day-to-day activities, andmanagement focuses on the release content or theiteration level. To overcome any micro-management, theScrum Master must take on a facilitator role and not ataskmaster role. The daily meetings should be used tosynchronize the teams and identify impediments and notto collect the project status. Therefore, time should bespent on future actions to bring out dependencies, issues,and communication between the team members. Thedaily meetings should be well organized and prompt butnot hurried.

VI. SUMMARIZATION AND CONCLUSIONProper 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.

7/28/2019 IJETAE_0312_16

7/8



103

VII. FUTURE SCOPEThe 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 managementapproach. 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 fromexperimenting 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 withScrum. Prentice Hall, 2002.

[2] Sutherland, Jeff. Inventing and Reinventing Scrum in fivecompanies, 21 September 2001.

[3] R.L. Glass, InspectionsSome 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: ThePeople Factor, Computer, Nov.2001, pp. 131-133.

[6] [Suphak Suwanya and Werasak Kurutach Applying AgilityFramework in Small and Medium Enterprises ASEA 2009, CCIS59, pp. 102110, 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. MikeKonrad,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 andPractice of Reducing and Merging XP with Heavy Soft wareDeveloping Process Journal of Computer Engineering andApplications 2003.22

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

[11] Tom Demarco Software Engineering: An Idea Whose Time HasCome 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. TechnicalReport.Colorado State University, 2002.

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

[15] LanCao; Mohan, K; PengXu; Ramesh, B.How extreme doesextreme programming have to be? Adapting XP practices to large-scale projectsProceedings of the 37th Annual Hawaii InternationalConference onSystem Sciences, 2004.

[16] He Huang, Peiji Tao, Xianming, Liu, Qiang Cui Research andPractice of Reducing and Merging XP with Heavy Soft wareDeveloping Process Journal of Computer Engineering andApplications 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, IEEESoftware,vol. 6, no. 3, pp. 31-36, May/June 1989.

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

[22] J Wyrynen, M Bodn, G Bostrm Security Engineering andeXtreme Programming: an Impossible marriage?ExtremeProgramming and Agile Methods - XP/Agile Universe 2004SpringerBerlin / Heidelberg

[23] Barry Boehm Richard Turner Balancing agility and discipline: aguide 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 CodeReviews on Software Quality: An Empirical Study Based on PSPData, 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 SystemEnvironments, June 1995, National Aeronautics and SpaceAdministration, Goddard Space Flight Center, Greenbelt Maryland

7/28/2019 IJETAE_0312_16

8/8



104

[29] Tu Honglei1, Sun Wei1, Zhang Yanan1, The Research on SoftwareMetrics and Software Complexity Metrics, International Forum onComputer 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 heoffered in the course of my studies. His encouragement and

guidance have been of great value to me Personally, I would alsolike to thank my parents and my partner for their support in mystudies.

AUTHORSPROFILE

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.

IJETAE_0312_16

Documents

Transcript of IJETAE_0312_16