{"id":8297,"date":"2023-04-04T11:47:33","date_gmt":"2023-04-04T16:47:33","guid":{"rendered":"https:\/\/alaafiaafrc.org\/adtc\/?p=8297"},"modified":"2023-04-04T11:57:00","modified_gmt":"2023-04-04T16:57:00","slug":"software-engineering-metrics-are-a-way-to-measure-the-quality-and-health-of-your-software-development-process","status":"publish","type":"post","link":"https:\/\/alaafiaafrc.org\/adtc\/software-engineering-metrics-are-a-way-to-measure-the-quality-and-health-of-your-software-development-process\/","title":{"rendered":"What are software engineering metrics?"},"content":{"rendered":"<div class=\"text-rte text section\">\n<div id=\"text-rte-f50ed504a4\" class=\"cmp-text\">\n<h1 class=\"resource-title\">17 software engineering metrics + how to track them<\/h1>\n<p>Software engineering metrics are a way to measure the quality and health of your software development process. These metrics should be objective, simple to understand, and consistently tracked over time.<\/p>\n<p>While teams may try to \u201cgame\u201d the metrics in their organization, this will end up hurting your team in the long run. Software engineering metrics should be used as objective signals to drive better outcomes for your organization.<\/p>\n<p>It\u2019s important to note the difference between software engineering metrics and application and performance monitoring (APM) metrics. APM metrics (like website uptime) track the actual performance of a piece of software or app. Software engineering metrics, on the other hand, <a href=\"https:\/\/www.pluralsight.com\/blog\/teams\/best-practices-to-measure-software-engineer-performance\">measure team performance<\/a>, team health, and delivery predictability.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">Why are the metrics we see in Jira not enough?<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-38cc5c7dc7\" class=\"cmp-text\">\n<p>While Jira metrics provide a solid foundation for tracking fundamental Agile metrics, they don\u2019t encompass all aspects of the software development lifecycle.<\/p>\n<p>Jira metrics lack depth and highlight surface-level issues rather than showing leaders how to improve organizational performance. Tools like Pluralsight Flow merge various software engineering metrics to provide you with a deep dive into historical trends, team health, and collaboration to help you identify bottlenecks in your process.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">Types of software engineering metrics<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-5119a7673a\" class=\"cmp-text\">\n<p>There are a number of software engineering metric types to focus on as a team. At the heart of these metrics, you want to look at how well your team is hitting goals and developing productive code.<\/p>\n<p>Software engineering metrics fall within a few distinct buckets and map to certain aspects of the software development lifecycle:<\/p>\n<ul>\n<li><b>Predictability: <\/b>Metrics under this category answer the questions \u201cAre we moving fast enough?\u201d and \u201cDo we have a steady, efficient pace?\u201d Understanding these metrics enable leaders to more predictably estimate outcomes, timelines, and ROI.<\/li>\n<li><b>Activity: <\/b>These metrics\u2014when used properly\u2014can show how organizational inefficiencies are getting in the way of work getting done.<\/li>\n<li><b>Culture:<\/b> Culture metrics answer the question, \u201cAre we instilling a collaborative culture in our software development process?\u201d Pull request metrics are key to seeing how collaborative your team is during the code review process.<\/li>\n<li><b>Efficiency: <\/b>These metrics evaluate how efficient your team is, whether there are processes or roadblocks hurting your team, and whether developers are taking feedback from their pull requests and iterating on it.<\/li>\n<li><b>Reliability:<\/b> Reliability metrics work as a sort of control variable to help teams understand if they\u2019re sacrificing quality for speed.<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h2 id=\"coding-metrics\" class=\" \">Coding metrics<\/h2>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-4943885a39\" class=\"cmp-text\">\n<p>Coding metrics allow developers to track and measure the quality of code they\u2019re creating. Tracking this historical data provides the insights teams need to improve the reliability and maintainability of code.<\/p>\n<\/div>\n<\/div>\n<div class=\"image section\"><img decoding=\"async\" class=\" \" src=\"https:\/\/www.pluralsight.com\/content\/dam\/pluralsight2\/siege-blog-assets\/4-coding-metrics-for-software-engineering-teams.png\" alt=\"An image depicting four essential coding metrics to track and how they're measured\" data-airgap-id=\"28\" \/><\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">1. Lead time for changes<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-2a300ee6d4\" class=\"cmp-text\">\n<p>Lead time for changes measures the time it takes from when code is committed to when it\u2019s deployed. This metric gauges how long it takes to create and deliver value to the user.<\/p>\n<p>A high lead time for changes can indicate there are bottlenecks within your software development process. A low lead time for changes shows that your team is efficient in reacting to changes\u2014whether it\u2019s responding to feedback, fixing a bug, developing a new feature, or maintaining your codebase.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">2. Deployment frequency<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-6448789371\" class=\"cmp-text\">\n<p>Deployment frequency measures how often code is successfully deployed into production. This metric measures a team\u2019s speed and agility. Teams deploying more often (such as several times a day or once a week) indicate elite or strong-performing teams.<\/p>\n<p>If your team is deploying less frequently (such as once every few weeks), it may be a sign to reduce your deployment size so it\u2019s easier to review, test, and deploy.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">3. Rework<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-eaba4fe331\" class=\"cmp-text\">\n<p><a href=\"https:\/\/help.pluralsight.com\/help\/what-is-rework\">Rework<\/a> is code that\u2019s rewritten or deleted within three weeks of being created. While some rework is to be expected, spikes in rework can indicate that an engineer is struggling with a project or that a project\u2019s requirements were unclear. For a senior engineer, a typical rework rate is between 20 &#8211; 30%.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">4. Impact<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-44f9afe1f7\" class=\"cmp-text\">\n<p>Impact measures the scale of changes to the codebase. This metric is an approximate measure of the cognitive load the engineer carried when implementing code changes. Impact is a good explainer metric\u2014if efficiency or coding days drops, was it due to work with above-average complexity?<\/p>\n<p>Impact takes into account:<\/p>\n<ul>\n<li>The amount of code in a change<\/li>\n<li>What percentage of the work is edits to old code<\/li>\n<li>The number of edit locations<\/li>\n<li>The number of files affected<\/li>\n<li>The severity of changes when old code is modified<\/li>\n<li>How this change compares to others from the project history<\/li>\n<\/ul>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">5. Legacy refactor<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-019d10a522\" class=\"cmp-text\">\n<p>Legacy refactor measures the updates and edits to code older than three weeks. Tracking this metric helps you better understand how much time is spent paying down <a href=\"https:\/\/www.pluralsight.com\/blog\/teams\/technical-debt-management-part1\">technical debt<\/a>.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">6. New work<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-b96df7147b\" class=\"cmp-text\">\n<p>New work is brand-new code that doesn\u2019t replace or fix other code. This metric shows the amount of code a team or individual writes for new products and features.<\/p>\n<p>Your new work target will depend on the stage of business you\u2019re in. For example, a new company might aim for more than half of their work to be new work, indicating you\u2019re building a new product.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">7. Commit complexity<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-68f75faccb\" class=\"cmp-text\">\n<p>Commit complexity measures how likely it is that a particular commit will cause problems. This metric calculation includes how large the commit is, the number of files it touches, and how concentrated the edits are. Commit complexity essentially looks at the riskiness associated with a commit.<\/p>\n<p>Commit complexity is an important metric to track because it can help teams prioritize which commits to review first\u2014and which commits will require extra time and attention.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h2 id=\"collaborative-metrics\" class=\" \">Collaborative metrics<\/h2>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-80f8615a25\" class=\"cmp-text\">\n<p>Team collaboration metrics give managers crucial insight into how teams are responding to the <a href=\"https:\/\/www.pluralsight.com\/blog\/tutorials\/code-review\">code review process<\/a>. These metrics provide insight into the overall collaboration and team culture, as well as bottlenecks impacting deployment.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"image section\"><img decoding=\"async\" class=\" \" src=\"https:\/\/www.pluralsight.com\/content\/dam\/pluralsight2\/siege-blog-assets\/6-collaborative-metrics-to-know.png\" alt=\"Image depicts six essential collaborative team metrics to track \" data-airgap-id=\"29\" \/><\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">8. Responsiveness<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-9fd928a457\" class=\"cmp-text\">\n<p>Responsiveness is a measure of how long it takes a submitter to respond to a comment on their pull request with another comment or code revision. This metric gives teams insight into whether team members are responding to code review feedback in a timely manner.<\/p>\n<p>Lowering this metric ensures that pull requests are being reviewed and merged in an appropriate time frame. For context, the industry norm for leading contributors is 1.5 hours and six hours for typical contributors.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">9. Unreviewed PRs<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-a62b0e6ce7\" class=\"cmp-text\">\n<p>Unreviewed PRs is the percentage of pull requests without comments or approvals. This metric shows you how many pull requests are merged without being reviewed.<\/p>\n<p>Leading contributors typically have 5% unreviewed PRs, and typical contributors have 20% unreviewed PRs.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">10. PR iteration time<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-b6a0204a82\" class=\"cmp-text\">\n<p>PR iteration time is the average time in hours between the first and final comment on a pull request. This metric gives you insight into how long it takes to implement changes requested on PRs.<\/p>\n<p>High iteration time can indicate the initial pull request had poor or misaligned requirements or that the reviewer\u2019s requested changes were time-intensive and out of scope.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">11. Iterated PRs<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-0c19b7acff\" class=\"cmp-text\">\n<p>Iterated PRs is the percentage of pull requests with at least one follow-on commit. This simple metric allows you to see how many pull requests require additional work before being merged.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">12. Reaction time<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-293f0593fb\" class=\"cmp-text\">\n<p>Reaction time is the time it takes for a reviewer to review a pull request and respond to a comment. This metric helps answer the question: Are reviewers responding to pull requests in a timely manner?<\/p>\n<p>The goal is to drive this number down, as a lower reaction time indicates better collaboration between submitter and reviewer. A typical reaction time for a leading contributor is six hours, and 18 hours for a typical contributor.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">13. Thoroughly reviewed PRs<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-bc767f4727\" class=\"cmp-text\">\n<p>Thoroughly reviewed PRS is the percentage of merged pull requests with at least one regular or robust comment. This metric aims to ensure pull requests are being thoroughly reviewed.<\/p>\n<p>Too many pull requests without thorough reviews can be a sign of rubber-stamping during the code review process. On the flip side, a high thoroughly reviewed PRs percentage indicates strong code review quality and healthy team collaboration.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">14. Time to merge<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-daa349b1fc\" class=\"cmp-text\">\n<p>Time to merge is the average time in hours from when pull requests are created to when they\u2019re merged. This metric tells you how long pull requests are in review. Long-running pull requests can be costly to your business and result in delayed releases.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">15. Time to first comment<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-e7e1fc663e\" class=\"cmp-text\">\n<p>Time to first comment is the average time in hours from when pull requests are created to when they receive their first comment. Driving down this metric helps reduce waste, cycle time, and context switching.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">16. Follow-on commits<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-154f89d0b4\" class=\"cmp-text\">\n<p>Follow-on commits measure the number of code revisions added to a pull request after it is opened for review. Tracking this metric gives you insight into the quality of your code review process. If you see a spike in follow-on commits, that\u2019s an indication you may need better planning and testing.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h3 class=\" \">17. Sharing index<\/h3>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-9f64436c9e\" class=\"cmp-text\">\n<p>Sharing index measures how information is being shared across a team by looking at who\u2019s reviewing whose pull requests. Tracking the sharing index can help you understand the number of people regularly participating in code reviews.<\/p>\n<p>This metric is a great way to gauge how well senior members are sharing knowledge with more junior developers and identifying situations where knowledge silos are happening.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h2 id=\"benefits-of\" class=\" \">Benefits of tracking software engineering metrics<\/h2>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-8d5c68e9e3\" class=\"cmp-text\">\n<p>The goal of tracking these metrics should be to improve processes, quality, and collaboration across your team. The benefits of tracking software engineering metrics include:<\/p>\n<ul>\n<li>Increasing understanding of how work is being done<\/li>\n<li>Identifying problems\/bottlenecks<\/li>\n<li>Managing workloads and resources<\/li>\n<li>Drawing objective conclusions to aid in decision making and goal setting<\/li>\n<\/ul>\n<p>Of course, it\u2019s not enough to simply track software engineering metrics. You must also make it a habit to report on and review these metrics on a regular basis to track growth over time.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h2 id=\"how-to-align\" class=\" \">How to align software engineering metrics with your organizational goals<\/h2>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-f52c055821\" class=\"cmp-text\">\n<p>With so many metrics to track, it can be helpful to take a step back and consider your organizational goals as you\u2019re determining what metrics you want to prioritize.<\/p>\n<p>One way to do that is with the Goal\/Question\/Metric method. This method is broken down into three levels:<\/p>\n<ul>\n<li><b>Goals (conceptual level):<\/b> Start by defining the goals you\u2019re trying to achieve.<\/li>\n<li><b>Questions (operational level):<\/b> Ask clarifying questions you\u2019re trying to answer with the data you collect.<\/li>\n<li><b>Metrics (quantitative level):<\/b> Assign a set of metrics to every question to answer it in a measurable way.<\/li>\n<\/ul>\n<p>Goal\/Question\/Metric can be used for a variety of outcomes. You may want to use the method to improve technical quality, product quality, or delivery team health. Using Goal\/Question\/Metric will ultimately help you identify and clarify your business goals, and establish metrics that will help you track and measure progress toward these goals.<\/p>\n<\/div>\n<\/div>\n<div class=\"image section\"><img decoding=\"async\" class=\" \" src=\"https:\/\/www.pluralsight.com\/content\/dam\/pluralsight2\/siege-blog-assets\/goal-question-metric-method-example.png\" alt=\"Image depicting the goal question metric method with an example \" data-airgap-id=\"30\" \/><\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"title2 section\">\n<div data-emptytext=\"Title\">\n<h2 class=\" \">How Pluralsight Flow can help you measure key software engineering metrics<\/h2>\n<\/div>\n<\/div>\n<div class=\"text-rte text section\">\n<div id=\"text-rte-fda4847caa\" class=\"cmp-text\">\n<p>You can measure almost anything, but you can&#8217;t (and shouldn\u2019t) pay attention to everything. Pluralsight Flow helps you track the right metrics all within one DevOps metric dashboard to give you the workflow insights you need.<\/p>\n<p>To find out more about how Pluralsight Flow can help you track metrics beyond the standard Jira or DORA set, <a href=\"https:\/\/www.pluralsight.com\/product\/flow\">schedule a demo<\/a> with our team today.<\/p>\n<\/div>\n<\/div>\n<div class=\"spacer section\">\n<div class=\"spacer \"><\/div>\n<\/div>\n<div class=\"image section\"><a class=\" \" href=\"https:\/\/www.pluralsight.com\/product\/flow\/contact-sales-flow?utm_source=Siege-Flow-Blog&amp;utm_medium=banner&amp;utm_campaign=flow-forward&amp;utm_term=flow-global-software-engineering-metrics\" target=\"_self\" rel=\"noopener\"><img decoding=\"async\" class=\"image--center \" src=\"https:\/\/www.pluralsight.com\/content\/dam\/pluralsight2\/flow-assets\/PS12-Contact-Sales-Banner_RD2.png\" alt=\"Contact Flow sales\" data-airgap-id=\"31\" \/><\/a><\/div>\n<div class=\"spacer section\"><\/div>\n","protected":false},"excerpt":{"rendered":"<p>17 software engineering metrics + how to track them Software engineering metrics are a way to measure the quality and health of your software development process. These metrics should be [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":7428,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/posts\/8297"}],"collection":[{"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/comments?post=8297"}],"version-history":[{"count":3,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/posts\/8297\/revisions"}],"predecessor-version":[{"id":8300,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/posts\/8297\/revisions\/8300"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/media\/7428"}],"wp:attachment":[{"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/media?parent=8297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/categories?post=8297"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alaafiaafrc.org\/adtc\/wp-json\/wp\/v2\/tags?post=8297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}