tracking scrum projects tools, metrics and myths about agile
TRANSCRIPT
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
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.
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
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.
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.
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.
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.
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
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.