You are on page 1of 8

International Journal of Emerging Technology and Advanced Engineering

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

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 Department of Computer Science, Amity University, Noida, India
1

er.monika.silent@gmail.com 2 rmajumdar@amity.edu

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. KeywordsScrum metrics; Tracking Tools; Myths about Agile; Agile Metrics; Agile and CMMI; Bundown Chart; Progress Chart; Agile with Project Management tools.

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

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.

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. 97

International Journal of Emerging Technology and Advanced Engineering


Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012) A. The ideal days technique The 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 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 98 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) 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 selfstick 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 selfstick 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.

99

International Journal of Emerging Technology and Advanced Engineering


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

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. 100

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 definableso that it is clear how the 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.

International Journal of Emerging Technology and Advanced Engineering


Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012) 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. 101

International Journal of Emerging Technology and Advanced Engineering


Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012) 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. 102 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) 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.
[17] [18] [19] [20] [7] [8] Entry SCRUM in Wiki website. http://en.wikipedia.org/wiki/Scrum_(development) 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. 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 Hui Li, Peiji Tao, Wenfeng Li Combining XP and RUP to develop small projects Computer Engineering & Design 2005 Tom Demarco Software Engineering: An Idea Whose Time Has Come and Gone? IEEE Software, July/August 2009, pp95-96 www.mountaingoatsoftare.com/scrum/ Turk, D., France, R., Rumpe, B. Agile SoftwareProcesses: Principles, Assumptions and Limitations. Technical Report.Colorado State University, 2002. Watts S. Humphrey PSP: A Self-Improvement Process for Software Engineers Addison-Wesley, 2005 LanCao; Mohan, K; PengXu; Ramesh, B.How extreme does extreme programming have to be? Adapting XP practices to largescale projectsProceedings of the 37th Annual Hawaii International Conference onSystem Sciences, 2004. 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 www.controlchaos.com/scrumwp.html Tobias Mayer The Essence of SCRUM http://agilethinking.net/essence-of-scrum.html http://agilealliance.com/articles/articles/InventingScrum.pdf 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. 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. J Wyrynen, M Bodn, G Bostrm Security Engineering and eXtreme Programming: an Impossible marriage?Extreme Programming and Agile Methods - XP/Agile Universe 2004Springer Berlin / Heidelberg Barry Boehm Richard Turner Balancing agility and discipline: a guide for the perplexed Addison-Wesley, 2004 Cockburn, A. Agile Software Development.Bostom:AddisonWesley 2002 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 Extreme Chaos, The Standish Group International, 2001. 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 Software Quality Metrics for Object Oriented System Environments, June 1995, National Aeronautics and Space Administration, Goddard Space Flight Center, Greenbelt Maryland

[9]

[10] [11] [12] [13]

[14] [15]

[16]

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] [2] [3] [4] [5] [6] Schwaber, Ken and Mike Beedle. Agile software Development with Scrum. Prentice Hall, 2002. Sutherland, Jeff. Inventing and Reinventing Scrum in five companies, 21 September 2001. R.L. Glass, InspectionsSome Surprising Findings, Comm.ACM, vol. 42, no. 4, pp. 17-19, Apr. 1999 SEI Supporting Tool web site, http://www.sei.cmu.edu/tsp/tools/studypsp-form.cfm A. Cockburn and J. Highsmith, Agile Software Development: The People Factor, Computer, Nov.2001, pp. 131-133. [Suphak Suwanya and Werasak Kurutach Applying Agility Framework in Small and Medium Enterprises ASEA 2009, CCIS 59, pp. 102110, 2009 Springer-Verlag Berlin Heidelberg 2009

[21]

[22]

[23] [24] [25]

[26] [27]

[28]

103

International Journal of Emerging Technology and Advanced Engineering


Website: www.ijetae.com (ISSN 2250-2459, Volume 2, Issue 3, March 2012)
[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
1

Ms. 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.
2

Mr. 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.

104

You might also like