Agile Governance Framework with MKII Function Points
July 13, 2015
An Insider view by Meetu Singh
Agile metrics framework for organizations
The outsourcing industry prefers to adopt Agile because the customer gets regular visibility into and better control of the development cycle. The intent of this paper is to share my experiences at InterGlobe Technologies while implementing Scrum in a distributed environment, with the function point (FP) estimation method, and defining a scalable Agile metrics framework.
The main reason for FP adoption was to overcome the following challenges that Scrum teams face when setting up governance around Agile:
- How to measure the productivity of multiple Scrum teams at a platform, an organization, or an account level
- What team composition helps achieve the expected output
- To implement the risk-sharing delivery model, what is the basis for SLAs (service-level agreement) and KPI (key performance indicator) agreement with customers
Adoption of the FP method helps elevate metrics management, governance, and SLAs to the next level.
Why the function point?
The story point estimation technique as part of Scrum is relative in nature, depending on the team’s knowledge and capability, which tends to change over time. Dealing with multiple project teams at various locations and across geographies demands a standardized and scientific method of estimation that removes subjectivity and reduces variation.
A function point (FP) is a unit of measurement used to express the amount of business functionality an information processing system provides to an end user. An FP measures software size, and there are many standards adopted by the industry. Mark II method (ISO/IEC 20968 Software engineering – Mk II Function Point Analysis) is a widely used method of measuring the functional size of software. In MKII, software requirements are expressed in terms of logical transactions (LT), each comprising an input, process, and output component.
Below is the high-level process for arriving at an FP count for requirements or user stories:
- Identify the application boundary for the purpose of the FP count.
- Identify the functional requirements and logical transactions.
- Identify the processing components or entities of all logical transactions.
- Identify the input and output components for each logical transaction.
- Calculate the logical transaction size to arrive at the unadjusted function point (UFP).
- Apply the value adjustment factor (VAF) to arrive at the adjusted function point (AFP).
Organizations with commitments to Capability Maturity Model Integration (CMMI) or other process improvement programs require a collection of standard metrics like SLAs, defect density (pre and post), and productivity at various levels that are easily achievable while adopting the MK II function point method.
Agile metrics framework based on the function point
The objective of a metrics framework is to assess performance at various levels and to implement improvement initiatives by using six sigma and CMMI® High Maturity practices. Having a common method and metrics defined as part of the framework has enabled us to assess the performance at four different levels:
- Organization level
- Product level
- Account level
- Scrum team level
FP sizing is done at different levels by using defined counting rules and standard calculations, which results in less variation among Scrum teams. FP counting is aligned with Scrum ceremonies and work products, such as the product backlog and the sprint backlog. Performing FP sizing at different levels enables the capture of delta in product requirements and helps in gauging the requirements stability index.
Product or account level stages
- Application or product level. Product level FP sizing, as part of the product backlog, is done in the initial stage to arrive at the approximate FP count at 30 percent to 40 percent visibility into detailed requirements. Epics captured as part of the product backlog are sized in FPs to arrive at the functional size at this level.
- Release level. Based on discussions with product owners and according to the current design and nonfunctional requirements, the module or phase-level FP sizing for prioritized stories and epics is done as part of the product backlog.
Scrum-team level stages
- Sprint level. Story grooming is complete. To arrive at the expected or estimated functional size that the Scrum teams must deliver, the FP sizing and resizing is also completed as part of the sprint.
- Sprint delivery level. Actual FP counting is done based on the features developed by Scrum teams to validate the estimated FP size story-wise.
When the FP count is available at the product backlog level, the next question is to decide how many FPs to develop as part of a sprint. These FPs should be defined as sprint goals in terms of user stories. To calculate the capacity or the velocity of Scrum teams, the productivity target (e.g., hours per FP) is taken from the organization capability baseline. If Agile is implemented for the first time, then the organization capability baselines may not be available. In such situations, industry data or trial limits can be set. You can revise them as soon as sufficient data is available.
Following is a sample illustration on how to arrive at the FP goal for the sprint level and estimate the expected time to complete the project.
For example:
1 FP = 15 hours (Scrum team productivity)
1 sprint = 10 working days
7.5 resources
Productivity of the team per iteration: 7.5 x 10 x 8 = 600 Phrs (available hours)
Therefore, the FP goal is 600 /15 = 40 FPs
You can calculate the total FPs to be delivered based on the number of Scrum teams. This helps plan the time lines by delivery team to give deeper insights into the customer on the product’s time-to-market.
The table below illustrates how to calculate productivity at different levels for one sprint. You can also analyze the calculation for a Scrum team across multiple sprints.
The calculations are based on the following assumptions:
- Common technology platform across products
- Team size is 7.5, distributed over one business analyst
- One developer, two senior developers, two testers, one senior tester, and half of a ScrumMaster. One ScrumMaster can look after two Scrum teams.
Note: To demonstrate the example, the standard average formula was used. However, to assess any inconsistencies in processes, other statistical analyses are recommended.
| Program/ Product Level |
Scrum Team Level | Sprint # n Output in FPs (Velocity) | Scrum Induced Defects | Customer Reported Defects | Productivity in Hrs | Average Productivity at Product Level | Average Productivity at Account Level | Average Productivity at Org Level |
| Product A | Scrum Team 1 | 45 | 8 | 3 | 13.33 | 13.44 | 12.80 | 13.26 |
| Scrum Team 2 | 40 | 10 | 2 | 15.00 | ||||
| Scrum Team 3 | 50 | 12 | 4 | 12.00 | ||||
| Product B | Scrum Team 1 | 45 | 5 | 4 | 13.33 | 12.15 | ||
| Scrum Team 2 | 54 | 7 | 2 | 11.11 | ||||
| Scrum Team 3 | 50 | 9 | 6 | 12.00 | ||||
| Product C | Scrum Team 1 | 56 | 16 | 7 | 10.71 | 13.02 | 13.73 | |
| Scrum Team 2 | 45 | 11 | 4 | 13.33 | ||||
| Scrum Team 3 | 40 | 12 | 0 | 15.00 | ||||
| Product D | Scrum Team 1 | 45 | 3 | 1 | 13.33 | 14.44 | ||
| Scrum Team 2 | 36 | 24 | 6 | 16.67 | ||||
| Scrum Team 3 | 45 | 12 | 2 | 13.33 |
Based on the data in the table, we can also arrive at capability by using the following metrics:
- Defect Density Scrum Induced = Number of defects induced at the Scrum-team level / number of delivered FPs
- Defect Density Customer Reported = Number of defects reported by the customer / Number of delivered FPs
- Velocity = Number of delivered FPs
This data helps to gauge the performance at the Scrum team, product, account, and organization levels. To agree on SLAs with existing or potential customers, you can refer to the current performance measured.
Conclusion
The FP method provides several benefits and advantages to the team, account, and organization. It helps with quantifying the Agile performance at various levels, which can be leveraged with existing and potential customers.
Although the FP size at the application level frequently changes in the Agile environment, the actual size can be validated at sprint delivery. Team composition also plays a critical role in finalizing the expected output in terms of FP for a team. This gives visibility to both the internal teams and the customers regarding the time lines or budget. When defining or benchmarking the productivity numbers at the team, project, account, or organization level, applying CMMI® High Maturity practices also becomes easy.
An article by Meetu Singh in Scrum Alliance.
InterGlobe Technologies
