Software metrics plan template

Feature Completion Rate — Feature completion rate describes the number of features completed in each iteration or release. Feature Burndown Chart — Teams use a feature burndown chart to estimate the pace of work accomplished daily. The pace is usually measured in hours of work, although no specific rule prevents the team from measuring in feature points. Release Burnup — Release burn up charts measure the amount of work completed for a given release based on the total amount of work planned for the release.

Usually feature points are used as the unit of measure to show planned and completed work. Number of Blockers — A blocker is an issue that cannot be resolved by the individual assigned to complete the activity and requires assistance to overcome. Number of blockers describes the number of events that prohibit the completion of an activity.

Software Quality Metrics Recidivism Rate — Recidivism describes stories that are returned to the team for various reasons. Defect Count — Defect count measures the number of defects per iteration or release.

Change Fail Rate — The percentage of changes to the production system that fail. Software Development Progress Deployment Frequency — Deployment frequency provides information on the cadence of deployments in terms of time elapsed between deployments.

Progress against Roadmap — Progress measures major capabilities planned versus delivered. Cost Metrics Total Cost Estimate — This metric provides the total estimated cost for the product being developed or the service being acquired.

The cost estimation approach can depend on whether the program is seeking services over time e. Burn Rate — Burn rate measures incurred cost over time e. Delivered Value Points — This metric represents the count of value points delivered to users for a given release.

Value points are usually defined by the users or user representatives to indicate the business value assigned to a given feature or story. Level of User Satisfaction — This metric represents the degree of user satisfaction based on the value delivered by the product or solution. Metrics Considerations for Programs Implementing Agile Methods Programs implementing Agile metrics should consider taking the following actions to improve implementation success and pace of adoption.

Align on metrics to be collected. Identify tools to enable automation of metrics and supporting data to reduce the level of effort required to collect and report on metrics.

Document the metrics to be collected in a Metrics Plan. However, it is important to note that metrics must be established in an effort to directly improve the product or processes involved in the project.

They must be attributable to an established goal, threshold, or customer requirement or else they provide no value. This project quality metrics template provides both an outline and guide to developing your project quality metrics document. All metrics have been reviewed and approved by internal executive leadership and project sponsor as well as the customer, Argo Tooling Co. This section of the template should list the quality metrics chosen for this project and a description of each.

These descriptions should include an explanation of how the metric applies to the quality of the product or process it is being used to measure.

Additionally, any thresholds or limits should be clearly stated in this section. Metrics should always be clear, measurable, controllable, and reportable. Based on customer product requirements, internal process standards, and applicable industry standards, the following metrics have been established for the Beta Tool Project.

These metrics have been reviewed and approved internally and with the customer, Argo Tooling Co. Tensile Strength: The Beta Tool will be used in various industrial environments under high material stress loads. Based on anticipated customer usage and industry tooling standards, it has been determined that the tensile strength of the Beta Tool must meet or exceed mega-pascals MPa.

Tensile strength will be measured for each prototype of ABC Corp. The results will be verified by ABC Corp. Shear Strength: The Beta Tool will be subject to potentially high stress torque loads in various applications. Based on anticipated customer usage and industry tooling standards, it has been determined that the shear strength of the Beta Tool must meet or exceed MPa. Shear strength will be measured for each prototype on ABC Corp. Each prototype will be tested by a panel of Argo technicians on various criteria.

Argo technicians will be asked to rate the Beta Tool on a scale of 1 to 10 for each criteria. The scores will then be calculated to determine a total average score. Defect Report XII. Test Summary Report. A high-level company level document describes the principles, approach, and major objectives of the organization regarding Testing. A high-level document of the Test Levels to be performed and the Testing within those levels for an Organization.

Table of Contents 1. A Sample Test Strategy Document. This is essentially the executive summary part of the plan. This is not a technical description of the software, but a Users view of the functions. Overall rules and processes should be identified.

A Sample Test Plan Document. This is the document that connects the requirements to the test cases. The connection or mapping of the requirements to test cases is many to many. This means that one requirement is tested by one or more test cases. Conversely, it is possible to have one test case addressing one or more requirements. A set of input values, execution preconditions, expected result, and execution postconditions developed for a particular objective or Test condition.