PM Essence
Statistical approach in the Agile Framework

- Priyanka Dutta, R.T. Sundari, CDAC

Business in current scenario is different from what it used to be a few years ago. Here we will see practicing Agile Framework in a project Pre-Examination Process Automation System (PEPAS) to design, develop, maintain and host the application to perform the task easily at client end. We will also discuss, how the probability of project success increased by applying proven principal and practices of statistical approach such as Quantitative Project Management (QPM), Causal Analysis and Resolution (CAR) and Individual Moving Range (XMR) to mitigate the challenges.

Agile methodology was adopted to execute the project due to constraints of time in developing, testing and implementing the project and to respond to changes quickly and smoothly.

Implementation of Agile in Project

An error – free speedy interface is vital for successful functioning of the system. Most of the promising objectives of any software development method
or process are delivering working software on time, quality and budget. There were many challenges while building the application:

“This does not mean that an unfinished product is delivered, because of the that 80% of the project comes from 20% of the system requirements.”

1. The work order from start to finish is of very short duration of 25 to 40 days.
2. The date of completion of the project is not flexible as it is published in newspapers
3. We had to consistently fulfill all the requirements of the client even though it comes at the last moment.
4. Minimize the maintenance cost of the application and increase its productivity/performance at the same time due to short duration.
5. The load on the system is not known and is unexpected.

Consequently, Dynamic System Development Method (DSDM), a key agile framework was put to use for rapid application development. Using DSDM in our project, the time and resources for development are fixed and the functionality is decided accordingly. Our focus is on business need and timely delivery of product. DSDM talks about many core techniques but we implemented the following listed ones: Time boxing, MoSCoW, Prototyping and Testing.

Project was divided into two parts. Timelines were set for each and every activity and a work plan was made at the beginning of the project. Constraints were highlighted. For each part, number of requirements was selected according to the MoSCoW principle. Because time and budget were fixed, the only remaining variable was the requirements. So if a project is running out of time the requirements with the lowest priority are omitted. This does not mean that an unfinished product is delivered, because of the Pareto principle that 80% of the project comes from 20% of the system requirements, so as long as those most important 20% of requirements are implemented into the system, the system meets the business needs. The prototype model was developed and accepted by client. After acceptance the client placed different work orders. For every work order, customization of the base model was to be made as per the requirements. This was done at an early stage of the project.

Statistical Approach in Project Management

Research has shown that Quantitatively Managing the project produces better result and improves product quality. For practicing the Quantitative Project Management (QPM) following steps are to be followed:

1. Establish the Project Objectives
2. Select the Organizational Process Performance Model (PPM) that aligns with the project objective
3. Quantitatively assess the project status
4. Select the process that needs the improvement

Efforts efficiency can be attained by improving the Defect Density (DD). Hence the organization PPM of DD is selected for monitoring project progress and predicts the quality of the product.

The above PPM has SRS Review Effectiveness, Design Review Effectiveness and Code Review Effectiveness (CRE) as the coefficients. Crucial for this project is Code Review Effectiveness (CRE) and this has been chosen for statistical management. The goal for achieving DD was set as 4.2. At the beginning of the project CRE was at 39% and the probability of achieving DD 4.2 was 66%. After simulations it was concluded that with 43% Code Review Effectiveness the probability of achieving 4.2 DD was 97%. The values indicated that there was a need to improve the process.

D.D = 1.34 - 13.9 SRS Review Effectiveness + 2.16 Design Review Effectiveness - 1.40 Code Review Effectiveness.


Causal Analysis and Resolution (CAR) is done to identify how to increase the effectiveness in code review to make it a capable process. For doing Causal Analysis and Resolution (CAR) we used 5 Whys technique. The 5 Whys is a questions-asking method used to explore the cause/effect relationships underlying a particular problem with the goal of determining a root cause of a defect or problem.To monitor the progress of the project towards achieving the established goal, Individuals Moving Range (X-mR) control chart was chosen. Compare to all other control charts X-mR chart is more relevant for software projects. X-mR chart is a pair of control charts for processes with a subgroup size of one. It is used to determine if a process is stable and predictable, it creates a picture of how the system changes over time. The individual (X) chart displays individual measurements. The moving range (MR) chart shows variability between one data point and the next. Individuals and moving range charts are also used to monitor the effects of process improvement theories. Above chart shows the progress of the project. In the chart, before corrective action the mean value of the Defect Density is 5.65. This was higher than the upper specification limit of 4.3 DD. But after the aforementioned improvements we started monitoring the progress of the project using X-mR chart, there is no major deviation towards negative side of the project goal. At the end of the continuous monitoring, the natural limits start falling within the range of specification limits. The mean value of the Defect Density also reduced to 1.35.