Nowadays, as the software industry is slowly becoming more mature, software measurement and performance measurement are becoming increasingly important. Organizations need to know their productivity and competitiveness in software development projects for various reasons. In many software development contracts, targets are set for the suppliers to reach. These targets are based on software metrics like productivity, speed of delivery and software quality. In order to check if the targets are reached, it is necessary to measure the functional size of the software product that is delivered and also the functional size of the software development project that is carried out, as there is usually a difference between these two sizes. To be able to use functional size in contracts, it must be measured in an objective, repeatable, verifiable and therefore defensible way. That being the case, the industry’s best practice is to use an ISO/IEC standard for functional size measurement, e.g. Nesma, COSMIC or IFPUG function points. However, these methods only measure the functional user requirements from the total software requirements to be delivered. In activities like project estimation and productivity measurement, the influence of the non-functional requirements is expressed in the Project Delivery Rate (PDR) which is expressed in effort hours per function point. If more than the average amount of non-functional requirements need to be realized in a project (or more severe non-functional requirements), the PDR used should also be higher. In the industry it is customary to set productivity targets based on an average (or calibrated) influence of non-functional requirements and this works quite fine in traditional software projects. In software development projects that are executed in an agile way, this is not always the case. When working agile, there are forces that influence the traditional way of performance measurement significantly, resulting in a number of serious issues. In this paper these issues are explained and a method to overcome these issues is proposed.
Comparative Agile Measurement System - Ciklum White PaperCiklum Ukraine
Now when Agile software development is becoming very popular globally due to its proven effectiveness in reducing the cycle between idea generation and realization, minimizing risk of project goals’ misunderstanding, decreasing costs of addressing mistakes in software development and so on, many businesses need to monitor own adherence to Agile practices, measure efficiency of their distributed Agile teams, calculate ROI in their Agile Scrum education, etc.
As de facto there are no industry standards for measuring Agile effectiveness, it does not matter how good companies think they are at Agile unless they compare themselves against their peers and competitors.
After several years of consulting with the Agile development and project management gurus and thorough analysis of Agile behavior patterns from more than 80 clients’ own nearshore Agile software development teams, Ciklum has developed an innovative tool to measure Agile effectiveness – the Comparative Agile Measurement System (CAMS).
This framework aims to:
- Gauge productivity of distributed Agile teams in terms of teamwork, planning, knowledge, quality of delivery, technical practices, culture and requirements
- Visualize productivity gaps and detect roots of those gaps
- Develop solutions to improve teams’ productivity based on Agile best practices collected from more than 80 Ciklum Client Own Software Development Teams
This white paper aims to:
- Provide Agile practitioners with insights into the tool's background and application to distributed software development, and
- Demonstrate real-life cases of CAMS usage by such clients as Berlingske Media (Mecom Group) and Intranote
Nowadays, as the software industry is slowly becoming more mature, software measurement and performance measurement are becoming increasingly important. Organizations need to know their productivity and competitiveness in software development projects for various reasons. In many software development contracts, targets are set for the suppliers to reach. These targets are based on software metrics like productivity, speed of delivery and software quality. In order to check if the targets are reached, it is necessary to measure the functional size of the software product that is delivered and also the functional size of the software development project that is carried out, as there is usually a difference between these two sizes. To be able to use functional size in contracts, it must be measured in an objective, repeatable, verifiable and therefore defensible way. That being the case, the industry’s best practice is to use an ISO/IEC standard for functional size measurement, e.g. Nesma, COSMIC or IFPUG function points. However, these methods only measure the functional user requirements from the total software requirements to be delivered. In activities like project estimation and productivity measurement, the influence of the non-functional requirements is expressed in the Project Delivery Rate (PDR) which is expressed in effort hours per function point. If more than the average amount of non-functional requirements need to be realized in a project (or more severe non-functional requirements), the PDR used should also be higher. In the industry it is customary to set productivity targets based on an average (or calibrated) influence of non-functional requirements and this works quite fine in traditional software projects. In software development projects that are executed in an agile way, this is not always the case. When working agile, there are forces that influence the traditional way of performance measurement significantly, resulting in a number of serious issues. In this paper these issues are explained and a method to overcome these issues is proposed.
Improve Estimation maturity using Functional Size Measurement and Historical ...Harold van Heeringen
Many software projects still fail in recent years, also agile projects. Improving estimation maturity in order to start with a realistic estimate instead of an optimistic one can really save billions of dollars in most local software industries. The Chinese government may now be moving towards an active software estimation maturity improvement strategy in its new 5-year plan. Functional size measurement and relevant historical data as well as parametric estimation tools are key to such a strategy. This presentation was the key-note speech at the China System and Software Process Improvement Association conference on software estimation, Beijing China, May 27 2016.
Software Quality Dashboard Benchmarking StudyJohn Carter
Software metrics best practices from a benchmarking assignment that indicates how software metrics are reported to management and used to drive behavior. We learned how leading companies used dashboards to report on quality progress and improvement results. We found the best organizations focused on the vital few metrics but also had automated systems with the ability to drill down on metrics at the divisional and team levels. In addition, the best normalized the metrics by number of customers or complexity. They systematically used root cause analysis to analyze bugs in the field. The SW Quality metrics often went beyond the strict definition of quality in that they also measured release predictability and feature expectations. Finally, the best companies used external benchmarks to set their quality targets.
Comparative Agile Measurement System - Ciklum White PaperCiklum Ukraine
Now when Agile software development is becoming very popular globally due to its proven effectiveness in reducing the cycle between idea generation and realization, minimizing risk of project goals’ misunderstanding, decreasing costs of addressing mistakes in software development and so on, many businesses need to monitor own adherence to Agile practices, measure efficiency of their distributed Agile teams, calculate ROI in their Agile Scrum education, etc.
As de facto there are no industry standards for measuring Agile effectiveness, it does not matter how good companies think they are at Agile unless they compare themselves against their peers and competitors.
After several years of consulting with the Agile development and project management gurus and thorough analysis of Agile behavior patterns from more than 80 clients’ own nearshore Agile software development teams, Ciklum has developed an innovative tool to measure Agile effectiveness – the Comparative Agile Measurement System (CAMS).
This framework aims to:
- Gauge productivity of distributed Agile teams in terms of teamwork, planning, knowledge, quality of delivery, technical practices, culture and requirements
- Visualize productivity gaps and detect roots of those gaps
- Develop solutions to improve teams’ productivity based on Agile best practices collected from more than 80 Ciklum Client Own Software Development Teams
This white paper aims to:
- Provide Agile practitioners with insights into the tool's background and application to distributed software development, and
- Demonstrate real-life cases of CAMS usage by such clients as Berlingske Media (Mecom Group) and Intranote
Nowadays, as the software industry is slowly becoming more mature, software measurement and performance measurement are becoming increasingly important. Organizations need to know their productivity and competitiveness in software development projects for various reasons. In many software development contracts, targets are set for the suppliers to reach. These targets are based on software metrics like productivity, speed of delivery and software quality. In order to check if the targets are reached, it is necessary to measure the functional size of the software product that is delivered and also the functional size of the software development project that is carried out, as there is usually a difference between these two sizes. To be able to use functional size in contracts, it must be measured in an objective, repeatable, verifiable and therefore defensible way. That being the case, the industry’s best practice is to use an ISO/IEC standard for functional size measurement, e.g. Nesma, COSMIC or IFPUG function points. However, these methods only measure the functional user requirements from the total software requirements to be delivered. In activities like project estimation and productivity measurement, the influence of the non-functional requirements is expressed in the Project Delivery Rate (PDR) which is expressed in effort hours per function point. If more than the average amount of non-functional requirements need to be realized in a project (or more severe non-functional requirements), the PDR used should also be higher. In the industry it is customary to set productivity targets based on an average (or calibrated) influence of non-functional requirements and this works quite fine in traditional software projects. In software development projects that are executed in an agile way, this is not always the case. When working agile, there are forces that influence the traditional way of performance measurement significantly, resulting in a number of serious issues. In this paper these issues are explained and a method to overcome these issues is proposed.
Improve Estimation maturity using Functional Size Measurement and Historical ...Harold van Heeringen
Many software projects still fail in recent years, also agile projects. Improving estimation maturity in order to start with a realistic estimate instead of an optimistic one can really save billions of dollars in most local software industries. The Chinese government may now be moving towards an active software estimation maturity improvement strategy in its new 5-year plan. Functional size measurement and relevant historical data as well as parametric estimation tools are key to such a strategy. This presentation was the key-note speech at the China System and Software Process Improvement Association conference on software estimation, Beijing China, May 27 2016.
Software Quality Dashboard Benchmarking StudyJohn Carter
Software metrics best practices from a benchmarking assignment that indicates how software metrics are reported to management and used to drive behavior. We learned how leading companies used dashboards to report on quality progress and improvement results. We found the best organizations focused on the vital few metrics but also had automated systems with the ability to drill down on metrics at the divisional and team levels. In addition, the best normalized the metrics by number of customers or complexity. They systematically used root cause analysis to analyze bugs in the field. The SW Quality metrics often went beyond the strict definition of quality in that they also measured release predictability and feature expectations. Finally, the best companies used external benchmarks to set their quality targets.
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...John Carter
Applying Agile methods in a waterfall world seemed impossible until we discovered the 10 essential skills and tools. Five of these skills are organizational, while others translate the short intervals characteristic of Agile to the world outside of Software. User Stories becomes Boundary Conditions; Burn-down charts becomes Deliverable Hit Rate charts; Sprints become HW intervals; Sprint Retrospectives become Event Timeline Retrospectives, while the project as a whole is managed using Boundary Conditions. This presentation shows examples of these tools and shows examples of how they are applied.
Showcase the fundamentals of the agile methodology through the aid of stunning visuals using Agile Planning PowerPoint Presentation Slides. This compelling project planning PPT theme is replete with infographics, and other diagrams to help you convey the information precisely. Project managers can compare agile with other techniques like waterfall methodology and compile results through agile management PPT template. Illustrate agile methodologies like Scrum and extreme programming with the help of stimulating flowcharts included in agile project plan PowerPoint theme. Develop and present the team structure for agile in a concise manner by the means of agile process PPT slideshow. This agile framework PowerPoint presentation gives you a layout to present agile planning levels, and agile development lifecycle. Also, by using our scrum approach to planning PPT deck you can demonstrate the agile planning challenges and review sprints. Download the scrum model PowerPoint slideshow to get easy-to-edit slides like column chart, timeline graph, and percentage charts. https://bit.ly/3kWm3bS
Most of the agile framework focus on delivery part and provide no guidance on project initiation part. What are right questions to ask when we are in very first meeting with the sponsor? How to guide the sponsor through a process of converting high level business idea into a vision and go about chartering exercise? How to effectively conduct project initiation workshop and start with a discovery exercise that sets the scene for a project and produces an initial backlog? These are some of the concerns addressed in this presentation.
Estimation of agile functionality in software developmentBashir Nasr Azadani
Estimation of Agile Functionality in Software Development - ISBN: 978-988-98671-8-8
Publication date: Mar 21, 2008 presented at International MultiConference of Engineers and Computer Scientists 2008 Vol I
Many software development organizations work within the bounds of contractual agreements where the limitations imposed by the “Iron Triangle” of fixed timelines, budgets, and scope challenge their ability to embrace change and focus on value delivery. Agile practitioners often comment that agile contracting is a difficult problem, but proven solutions are rarely presented. Rachel Weston and Chris Spagnuolo offer some tools they have used in their own agile contracting work to help agile practitioners deal with different contracting scenarios while promoting agile practices, protecting the development organization, and still providing value and protection to the client’s organization. Through a combined workshop and facilitated collaborative session, Rachel and Chris present new agile contracting tools that can be added to your toolbox. You will gain a deeper understanding of the problems associated with agile contracting as well as practical solutions for dealing with contracts in an agile manner.
The beginning of a checklist version of the CMMI guidelines. If you would like the original Excel version let me know, and let SlideShare know they need to support Excel files.
This talk given at MeetMagento Poland 2014 presents my experience with doing Agile development and its challenges on development vs support projects. It will be a practical approach to project management, with how Agile can be applied inside a modern web development agency. Talk covers resource assignment, Scrum, Kanban, developer empowerment and continuous delivery with client satisfaction.
My presentation (in EN) from itSMF Pomorze (Poland) meeting. It shows how to combine SCRUM agility in product development with Corporate Governance controls from COBIT.
The Many approaches and methodologies are available in the development of software with error free to its end user by fulfilling the values of stake-holders. Among the available methodologies Agile is a popular methodology which is introduced in 2001. Agile consists of various development processes such as Scrum, XP, Kanban, Lean and others. Among them Lean is one of the methodology in development of software domain which is adapted from Toyota Production System. This paper concentrates on how Lean sustains in the business stagnation because there exists some problems such as missing deadline, over development and ineffective management. Lean is having its own advantages and pitfalls. To overcome the pitfalls of Lean an adaptive approach is needed which may fit with existing industry standards.
Quality by Design is a systematic approach to development that begins with predefined objectives and emphasizes understanding of the product and process, efficient process control, and quality risk management to improve the overall manufacturing quality. Implementing the Quality by Design (QbD) principles in manufacturing has resulted in reduced operating costs, highly efficient manufacturing processes and better positioning companies to meet increasing regulatory expectations.
QbD explains how to prioritize process parameters for screening designs, design robust processes using statistical design of experiments (DoE), bridge the bench and the commercial design spaces using mixing and scale-up calculations, quantify process risk, select suitable process analytical technology tools (PAT) and more.
To know more about Quality by Design training worldwide,
please contact us at -
Email: support@invensislearning.com
Phone - US +1-910-726-3695,
Website: https://www.invensislearning.com
The certification for Foundation Level Extension – Agile Tester is designed for professionals who are working within Agile environments. It is also for professionals who are planning to start implementing Agile methods in the near future, or are working within companies that plan to do so.
Too often we label software "done" when it’s not tested, only partially documented and only half ready for release. We produce no business value, we pile on technical debt, and stakeholders have no confidence in our status reports. This presentation explores how you can use Burndown charts to improve your process.
Agile Project Management in a Waterfall World: Managing Sprints with Predicti...John Carter
Applying Agile methods in a waterfall world seemed impossible until we discovered the 10 essential skills and tools. Five of these skills are organizational, while others translate the short intervals characteristic of Agile to the world outside of Software. User Stories becomes Boundary Conditions; Burn-down charts becomes Deliverable Hit Rate charts; Sprints become HW intervals; Sprint Retrospectives become Event Timeline Retrospectives, while the project as a whole is managed using Boundary Conditions. This presentation shows examples of these tools and shows examples of how they are applied.
Showcase the fundamentals of the agile methodology through the aid of stunning visuals using Agile Planning PowerPoint Presentation Slides. This compelling project planning PPT theme is replete with infographics, and other diagrams to help you convey the information precisely. Project managers can compare agile with other techniques like waterfall methodology and compile results through agile management PPT template. Illustrate agile methodologies like Scrum and extreme programming with the help of stimulating flowcharts included in agile project plan PowerPoint theme. Develop and present the team structure for agile in a concise manner by the means of agile process PPT slideshow. This agile framework PowerPoint presentation gives you a layout to present agile planning levels, and agile development lifecycle. Also, by using our scrum approach to planning PPT deck you can demonstrate the agile planning challenges and review sprints. Download the scrum model PowerPoint slideshow to get easy-to-edit slides like column chart, timeline graph, and percentage charts. https://bit.ly/3kWm3bS
Most of the agile framework focus on delivery part and provide no guidance on project initiation part. What are right questions to ask when we are in very first meeting with the sponsor? How to guide the sponsor through a process of converting high level business idea into a vision and go about chartering exercise? How to effectively conduct project initiation workshop and start with a discovery exercise that sets the scene for a project and produces an initial backlog? These are some of the concerns addressed in this presentation.
Estimation of agile functionality in software developmentBashir Nasr Azadani
Estimation of Agile Functionality in Software Development - ISBN: 978-988-98671-8-8
Publication date: Mar 21, 2008 presented at International MultiConference of Engineers and Computer Scientists 2008 Vol I
Many software development organizations work within the bounds of contractual agreements where the limitations imposed by the “Iron Triangle” of fixed timelines, budgets, and scope challenge their ability to embrace change and focus on value delivery. Agile practitioners often comment that agile contracting is a difficult problem, but proven solutions are rarely presented. Rachel Weston and Chris Spagnuolo offer some tools they have used in their own agile contracting work to help agile practitioners deal with different contracting scenarios while promoting agile practices, protecting the development organization, and still providing value and protection to the client’s organization. Through a combined workshop and facilitated collaborative session, Rachel and Chris present new agile contracting tools that can be added to your toolbox. You will gain a deeper understanding of the problems associated with agile contracting as well as practical solutions for dealing with contracts in an agile manner.
The beginning of a checklist version of the CMMI guidelines. If you would like the original Excel version let me know, and let SlideShare know they need to support Excel files.
This talk given at MeetMagento Poland 2014 presents my experience with doing Agile development and its challenges on development vs support projects. It will be a practical approach to project management, with how Agile can be applied inside a modern web development agency. Talk covers resource assignment, Scrum, Kanban, developer empowerment and continuous delivery with client satisfaction.
My presentation (in EN) from itSMF Pomorze (Poland) meeting. It shows how to combine SCRUM agility in product development with Corporate Governance controls from COBIT.
The Many approaches and methodologies are available in the development of software with error free to its end user by fulfilling the values of stake-holders. Among the available methodologies Agile is a popular methodology which is introduced in 2001. Agile consists of various development processes such as Scrum, XP, Kanban, Lean and others. Among them Lean is one of the methodology in development of software domain which is adapted from Toyota Production System. This paper concentrates on how Lean sustains in the business stagnation because there exists some problems such as missing deadline, over development and ineffective management. Lean is having its own advantages and pitfalls. To overcome the pitfalls of Lean an adaptive approach is needed which may fit with existing industry standards.
Quality by Design is a systematic approach to development that begins with predefined objectives and emphasizes understanding of the product and process, efficient process control, and quality risk management to improve the overall manufacturing quality. Implementing the Quality by Design (QbD) principles in manufacturing has resulted in reduced operating costs, highly efficient manufacturing processes and better positioning companies to meet increasing regulatory expectations.
QbD explains how to prioritize process parameters for screening designs, design robust processes using statistical design of experiments (DoE), bridge the bench and the commercial design spaces using mixing and scale-up calculations, quantify process risk, select suitable process analytical technology tools (PAT) and more.
To know more about Quality by Design training worldwide,
please contact us at -
Email: support@invensislearning.com
Phone - US +1-910-726-3695,
Website: https://www.invensislearning.com
The certification for Foundation Level Extension – Agile Tester is designed for professionals who are working within Agile environments. It is also for professionals who are planning to start implementing Agile methods in the near future, or are working within companies that plan to do so.
Too often we label software "done" when it’s not tested, only partially documented and only half ready for release. We produce no business value, we pile on technical debt, and stakeholders have no confidence in our status reports. This presentation explores how you can use Burndown charts to improve your process.
Balancing the Agile Equation: people x process
“Individuals and interactions over processes and tools” how often have you heard this phrase? I strongly believe in it however we see that a good balance between the two parts is the key to succeed. True respect for people means to provide them with what they need to get their job done. I this talk we will nuance “People over process” to “People times process” highlighting that if either are low, you get low productivity. Process does not ensure success, however a poor process needs heroes to succeed.
Agile Development Practices - ProductivityAlex Moore
Lunch and Learn I did on some general Agile and other practices that can make developers more productive.
Most of the content was in the speech though unfortunately.
PRODUCTIVITY OF AGILE TEAMS: AN EMPIRICAL EVALUATION OF FACTORS AND MONITORIN...Claudia Melo
Presenting my thesis during the National Thesis Contest in Computer Science - top 6 PhD Computer Science Thesis in Brasil/ 2013.
XXXIV Congresso da Sociedade Brasileira de Computação (CSBC 2014) - CTD.
Agile is a very popular project management method. It is especially useful in managing rapid deployment of new product features in measured cycles. SharePoint 2013 can be leveraged as a platform for managing Agile
Enterprise Agile release planning is complicated when multiple agile teams work together to deliver combined capabilities, and the scope for a release span across multiple business functions, processes, and systems. This paper presents agile release planning models for large global organizations delivering business capabilities using IT projects.
Metrics serve as important indicator of the efficiency and effectiveness of software process. Analysis of defined metrics helps identify area of improvement and devise subsequent actions.......Read more
Nowadays, all organization works on the principle of Agile methodology, there might be many people like me who don't even know the meaning of Agile and Scrum Master.
I have made the docs from the source available on the internet with all due respect have copied the URL LINK.
The motive behind posting this is you can get an Agile understanding in one document.
Thanks
This report from DCG Software Value discusses whether or not function points are still relevant in the IT world, given all the innovative changes and processes that have occurred.
Download this report here: http://ow.ly/108Vrw
This report from DCG Software Value discusses whether or not function points are still relevant in the IT world, given all the innovative changes and processes that have occurred.
6 Steps to Confirm Successful Workday DeploymentZaranTech LLC
Workday HCM Training & Certification provided Online from USA industry expert trainers with real time project experience
Workday HCM Tutorial for Beginners | Learn Workday HCM Online | Workday HCM training - This is a video recording of a Live Webinar presentation by our Sr. SAP Solution Architect and trainer who is also a Manager in handling SAP Implementation projects.
Get More Free Videos - Subscribe ➜ https://goo.gl/5ZqDML
COURSE PAGE: https://www.zarantech.com/workday-hcm-training/
REGISTER FOR FREE LIVE DEMO: http://promo.zarantech.com/free-webinar-workday-hcm/
CONTACT: +1 (515) 309-7846 (or) Email - info@zarantech.com
"workday hcm tutorial"
"free workday hcm training"
"online workday hcm training"
"Best workday hcm training"
"workday hcm training for Beginners"
"Best workday hcm Training"
Reviews / Testimonials from past trainees are saying: https://goo.gl/ZVfnE4
Refer your friends to ZaranTech - http://www.zarantech.com/be-a-friend-tell-a-friend.
How to Do Backlog Prioritization Easily and Efficiently _ StoriesOnBoard.pdfStoriesOnBoard
How to Do Backlog Prioritization
Easily and Efficiently?
- What is backlog prioritization and why it is important?
- How would you prioritize the backlog items?
- How do you decide which
features should take priority over others?
- Iteration planning, backlog maintenance, and backlog refinement
- How to prioritize a product backlog?
- Most common backlog prioritization techniques
- Prioritization with StoriesOnBoard
How to Reach Peak Performance With the Product Management Organizational Heal...Aggregage
The degree of maturity of your product management organization can directly drive your ability to satisfy customers and become more profitable. Our Product Management Organizational Health Checklist and on-demand webinar can help.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
The importance of benchmarking software projects - Van Heeringen and OgilvieHarold van Heeringen
Benchmarking is a crucial management activity that enables organizations to understand how competitive they are. Using functional size measurement methods and historical data enables organizations to improve their processes and become more succesful.
Avoid software project horror stories - check the reality value of the estima...Harold van Heeringen
Many large software projects turn into software horror stories, resulting in newspaper headlines and even political issues. Often, the project costs and schedule were estimated unrealistically optimistic, using immature estimation techniques. A relatively simple way to avoid many problems is to perform a reality check on the estimate. This presentation was given on the conference of the International Cost Estimating and Analysis Association (ICEAA2014), June 2014 (Denver, USA)
ISMA 9 - van Heeringen - Using IFPUG and ISBSG to improve organization successHarold van Heeringen
Introduction to the International Software Benchmarking Standards Group and 3 cases in which function points together with ISBSG data really resulted in business value:
- Reality check of an estimate made by experts
- Assessing the competitive position of a department
- Selecting a single software supplier
This presentation shows why it is important to benchmark the performance of software projects and organizations. Measurement of performance and comparing this to relevant peer groups provides the knowledge and understanding for managemenr to make informed decisions on where the organization stands and where it should go. This presentation was given at the Italian GUFPI-ISMA conference (December 2013) and addressed also the way the Italian industry is performing according to the ISBSG Country Analysis report.
Using the ISBSG data to improve your organization success - van Heeringen (Me...Harold van Heeringen
This presentation gives an introduction into the ISBSG organization and shows how the ISBSG products and data can help the software industry to become more mature. Three cases from personal experience are showed: a reality check of an expert estimate (that turned out to be optimistic), the analysis of the outgoing bids of a software supplier and the measurement of the performance of a single supplier, providing target productivity levels they should reach.
DevOps and metrics presentation, co-presentation by Dave van Herpen and Harold van Heeringen (both Sogeti Nederland B.V.). The key message of the presentation is the fact that metrics are important in DevOps environments and that it is important to do a thorough analysis of which metrics are important to collect and for which reasons.
In many organizations, bottom up estimation of software development projects is still the way to go. Management feels that top-down (parametric) estimation models require too much effort and cost. In this presentation, a random selection of 10 bids are analyzed and the bottom-up estimates and top-down estimates are compared with regard to accuracy and effort spend.
In many organizations, bottom up estimation of software development projects is still the way to go. Management feels that top-down (parametric) estimation models require too much effort and cost. In this paper, a random selection of 10 bids are analyzed and the bottom-up estimates and top-down estimates are compared with regard to accuracy and effort spend.
When clients outsource their software development projects, they need to make sure that these suppliers don't overprice the projects. As it is often not longer possible to select the best offer, there should be another mechanism to measure the value that they are getting in comparison to the money they are paying. Supplier Performance Measurement enables clients to keep in control of theis project costs in outsourcing situations and to negotiate performance improvements with the suppliers.
Project Control using functional size - which method to use?Harold van Heeringen
Project Control is one of the most difficult tasks of a project manager. To assess whether a project is still on track is very difficult because the team members often report overconfident status reports. Using functional size and specialized tooling, like QSM Control or SEER PPMC, helps the project manager to get a real good understanding of the status of the project. These tools produce accurate forecasts and offer the possibility to do what-if analysis in order to select the best way to get a project back on track. In this presentation, it is examined which method would produce the best results, NESMA or IFPUG FPA or COSMIC FPA.
Metrics based software supplier selection - Best practice used in the largest...Harold van Heeringen
Abstract—This article provides insight into a ‘best practice’ used for the selection of software suppliers at the largest Dutch telecom operator, KPN[1]. It explains the metrics rationale applied by KPN when selecting only one preferred supplier (system integrator) per domain instead of the various suppliers that were previously active in each domain. Presently (Q2 2012) the selection and contracting process is entering its final phase. In this paper, the model that was built and used to assess the productivity of the various suppliers and the results of the supplier selection process are discussed. In addition, a number of lessons learned and recommendations are shared.
The difference between expert estimates and parameteric estimates, and a study to see which ones are more accurate and faster to do. ISPA/SCEA conference, Brussels (May, 2012)
Accpac to QuickBooks Conversion Navigating the Transition with Online Account...PaulBryant58
This article provides a comprehensive guide on how to
effectively manage the convert Accpac to QuickBooks , with a particular focus on utilizing online accounting services to streamline the process.
Taurus Zodiac Sign_ Personality Traits and Sign Dates.pptxmy Pandit
Explore the world of the Taurus zodiac sign. Learn about their stability, determination, and appreciation for beauty. Discover how Taureans' grounded nature and hardworking mindset define their unique personality.
[Note: This is a partial preview. To download this presentation, visit:
https://www.oeconsulting.com.sg/training-presentations]
Sustainability has become an increasingly critical topic as the world recognizes the need to protect our planet and its resources for future generations. Sustainability means meeting our current needs without compromising the ability of future generations to meet theirs. It involves long-term planning and consideration of the consequences of our actions. The goal is to create strategies that ensure the long-term viability of People, Planet, and Profit.
Leading companies such as Nike, Toyota, and Siemens are prioritizing sustainable innovation in their business models, setting an example for others to follow. In this Sustainability training presentation, you will learn key concepts, principles, and practices of sustainability applicable across industries. This training aims to create awareness and educate employees, senior executives, consultants, and other key stakeholders, including investors, policymakers, and supply chain partners, on the importance and implementation of sustainability.
LEARNING OBJECTIVES
1. Develop a comprehensive understanding of the fundamental principles and concepts that form the foundation of sustainability within corporate environments.
2. Explore the sustainability implementation model, focusing on effective measures and reporting strategies to track and communicate sustainability efforts.
3. Identify and define best practices and critical success factors essential for achieving sustainability goals within organizations.
CONTENTS
1. Introduction and Key Concepts of Sustainability
2. Principles and Practices of Sustainability
3. Measures and Reporting in Sustainability
4. Sustainability Implementation & Best Practices
To download the complete presentation, visit: https://www.oeconsulting.com.sg/training-presentations
Skye Residences | Extended Stay Residences Near Toronto Airportmarketingjdass
Experience unparalleled EXTENDED STAY and comfort at Skye Residences located just minutes from Toronto Airport. Discover sophisticated accommodations tailored for discerning travelers.
Website Link :
https://skyeresidences.com/
https://skyeresidences.com/about-us/
https://skyeresidences.com/gallery/
https://skyeresidences.com/rooms/
https://skyeresidences.com/near-by-attractions/
https://skyeresidences.com/commute/
https://skyeresidences.com/contact/
https://skyeresidences.com/queen-suite-with-sofa-bed/
https://skyeresidences.com/queen-suite-with-sofa-bed-and-balcony/
https://skyeresidences.com/queen-suite-with-sofa-bed-accessible/
https://skyeresidences.com/2-bedroom-deluxe-queen-suite-with-sofa-bed/
https://skyeresidences.com/2-bedroom-deluxe-king-queen-suite-with-sofa-bed/
https://skyeresidences.com/2-bedroom-deluxe-queen-suite-with-sofa-bed-accessible/
#Skye Residences Etobicoke, #Skye Residences Near Toronto Airport, #Skye Residences Toronto, #Skye Hotel Toronto, #Skye Hotel Near Toronto Airport, #Hotel Near Toronto Airport, #Near Toronto Airport Accommodation, #Suites Near Toronto Airport, #Etobicoke Suites Near Airport, #Hotel Near Toronto Pearson International Airport, #Toronto Airport Suite Rentals, #Pearson Airport Hotel Suites
3.0 Project 2_ Developing My Brand Identity Kit.pptxtanyjahb
A personal brand exploration presentation summarizes an individual's unique qualities and goals, covering strengths, values, passions, and target audience. It helps individuals understand what makes them stand out, their desired image, and how they aim to achieve it.
Premium MEAN Stack Development Solutions for Modern BusinessesSynapseIndia
Stay ahead of the curve with our premium MEAN Stack Development Solutions. Our expert developers utilize MongoDB, Express.js, AngularJS, and Node.js to create modern and responsive web applications. Trust us for cutting-edge solutions that drive your business growth and success.
Know more: https://www.synapseindia.com/technology/mean-stack-development-company.html
India Orthopedic Devices Market: Unlocking Growth Secrets, Trends and Develop...Kumar Satyam
According to TechSci Research report, “India Orthopedic Devices Market -Industry Size, Share, Trends, Competition Forecast & Opportunities, 2030”, the India Orthopedic Devices Market stood at USD 1,280.54 Million in 2024 and is anticipated to grow with a CAGR of 7.84% in the forecast period, 2026-2030F. The India Orthopedic Devices Market is being driven by several factors. The most prominent ones include an increase in the elderly population, who are more prone to orthopedic conditions such as osteoporosis and arthritis. Moreover, the rise in sports injuries and road accidents are also contributing to the demand for orthopedic devices. Advances in technology and the introduction of innovative implants and prosthetics have further propelled the market growth. Additionally, government initiatives aimed at improving healthcare infrastructure and the increasing prevalence of lifestyle diseases have led to an upward trend in orthopedic surgeries, thereby fueling the market demand for these devices.
The world of search engine optimization (SEO) is buzzing with discussions after Google confirmed that around 2,500 leaked internal documents related to its Search feature are indeed authentic. The revelation has sparked significant concerns within the SEO community. The leaked documents were initially reported by SEO experts Rand Fishkin and Mike King, igniting widespread analysis and discourse. For More Info:- https://news.arihantwebtech.com/search-disrupted-googles-leaked-documents-rock-the-seo-world/
Improving profitability for small businessBen Wann
In this comprehensive presentation, we will explore strategies and practical tips for enhancing profitability in small businesses. Tailored to meet the unique challenges faced by small enterprises, this session covers various aspects that directly impact the bottom line. Attendees will learn how to optimize operational efficiency, manage expenses, and increase revenue through innovative marketing and customer engagement techniques.
RMD24 | Retail media: hoe zet je dit in als je geen AH of Unilever bent? Heid...BBPMedia1
Grote partijen zijn al een tijdje onderweg met retail media. Ondertussen worden in dit domein ook de kansen zichtbaar voor andere spelers in de markt. Maar met die kansen ontstaan ook vragen: Zelf retail media worden of erop adverteren? In welke fase van de funnel past het en hoe integreer je het in een mediaplan? Wat is nu precies het verschil met marketplaces en Programmatic ads? In dit half uur beslechten we de dilemma's en krijg je antwoorden op wanneer het voor jou tijd is om de volgende stap te zetten.
As a business owner in Delaware, staying on top of your tax obligations is paramount, especially with the annual deadline for Delaware Franchise Tax looming on March 1. One such obligation is the annual Delaware Franchise Tax, which serves as a crucial requirement for maintaining your company’s legal standing within the state. While the prospect of handling tax matters may seem daunting, rest assured that the process can be straightforward with the right guidance. In this comprehensive guide, we’ll walk you through the steps of filing your Delaware Franchise Tax and provide insights to help you navigate the process effectively.
"𝑩𝑬𝑮𝑼𝑵 𝑾𝑰𝑻𝑯 𝑻𝑱 𝑰𝑺 𝑯𝑨𝑳𝑭 𝑫𝑶𝑵𝑬"
𝐓𝐉 𝐂𝐨𝐦𝐬 (𝐓𝐉 𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬) is a professional event agency that includes experts in the event-organizing market in Vietnam, Korea, and ASEAN countries. We provide unlimited types of events from Music concerts, Fan meetings, and Culture festivals to Corporate events, Internal company events, Golf tournaments, MICE events, and Exhibitions.
𝐓𝐉 𝐂𝐨𝐦𝐬 provides unlimited package services including such as Event organizing, Event planning, Event production, Manpower, PR marketing, Design 2D/3D, VIP protocols, Interpreter agency, etc.
Sports events - Golf competitions/billiards competitions/company sports events: dynamic and challenging
⭐ 𝐅𝐞𝐚𝐭𝐮𝐫𝐞𝐝 𝐩𝐫𝐨𝐣𝐞𝐜𝐭𝐬:
➢ 2024 BAEKHYUN [Lonsdaleite] IN HO CHI MINH
➢ SUPER JUNIOR-L.S.S. THE SHOW : Th3ee Guys in HO CHI MINH
➢FreenBecky 1st Fan Meeting in Vietnam
➢CHILDREN ART EXHIBITION 2024: BEYOND BARRIERS
➢ WOW K-Music Festival 2023
➢ Winner [CROSS] Tour in HCM
➢ Super Show 9 in HCM with Super Junior
➢ HCMC - Gyeongsangbuk-do Culture and Tourism Festival
➢ Korean Vietnam Partnership - Fair with LG
➢ Korean President visits Samsung Electronics R&D Center
➢ Vietnam Food Expo with Lotte Wellfood
"𝐄𝐯𝐞𝐫𝐲 𝐞𝐯𝐞𝐧𝐭 𝐢𝐬 𝐚 𝐬𝐭𝐨𝐫𝐲, 𝐚 𝐬𝐩𝐞𝐜𝐢𝐚𝐥 𝐣𝐨𝐮𝐫𝐧𝐞𝐲. 𝐖𝐞 𝐚𝐥𝐰𝐚𝐲𝐬 𝐛𝐞𝐥𝐢𝐞𝐯𝐞 𝐭𝐡𝐚𝐭 𝐬𝐡𝐨𝐫𝐭𝐥𝐲 𝐲𝐨𝐮 𝐰𝐢𝐥𝐥 𝐛𝐞 𝐚 𝐩𝐚𝐫𝐭 𝐨𝐟 𝐨𝐮𝐫 𝐬𝐭𝐨𝐫𝐢𝐞𝐬."
Productivity measurement of agile teams (IWSM 2015)
1. Productivity measurement of agile teams –
overcoming the issues with non-functional
requirements.
Harold van Heeringen
METRI B.V.
Schiphol-Rijk, the Netherlands
harold.van.heeringen@metrigroup.com
Theo Prins
Sizing, Estimating & Control
Sogeti Nederland B.V.
Vianen, Nederland
theo.prins@sogeti.com
Edwin van Gorp
Sizing, Estimating & Control
Sogeti Nederland B.V.
Vianen, Nederland
edwin.van.gorp@sogeti.com
Abstract—Nowadays, as the software industry is slowly
becoming more mature, software measurement and performance
measurement are becoming increasingly important.
Organizations need to know their productivity and
competitiveness in software development projects for various
reasons. In many software development contracts, targets are set
for the suppliers to reach. These targets are based on software
metrics like productivity, speed of delivery and software quality.
In order to check if the targets are reached, it is necessary to
measure the functional size of the software product that is
delivered and also the functional size of the software development
project that is carried out, as there is usually a difference between
these two sizes. To be able to use functional size in contracts, it
must be measured in an objective, repeatable, verifiable and
therefore defensible way. That being the case, the industry’s best
practice is to use an ISO/IEC standard for functional size
measurement, e.g. Nesma, COSMIC or IFPUG function points.
However, these methods only measure the functional user
requirements from the total software requirements to be
delivered. In activities like project estimation and productivity
measurement, the influence of the non-functional requirements is
expressed in the Project Delivery Rate (PDR) which is expressed
in effort hours per function point. If more than the average
amount of non-functional requirements need to be realized in a
project (or more severe non-functional requirements), the PDR
used should also be higher. In the industry it is customary to set
productivity targets based on an average (or calibrated) influence
of non-functional requirements and this works quite fine in
traditional software projects. In software development projects
that are executed in an agile way, this is not always the case. When
working agile, there are forces that influence the traditional way
of performance measurement significantly, resulting in a number
of serious issues. In this paper these issues are explained and a
method to overcome these issues is proposed.
Keywords— agile development; story points, outsourcing,
performance measurement, functional requirements, Nesma,
ISBSG, non-functional requirements, Agile normalized size.
I. INTRODUCTION
These days, more and more software development projects
are carried out in agile oriented approaches like Scrum or
DSDM. Projects following an agile software development
method deliver software in an iterative way. The iterations are
usually called sprints. The main idea behind agile software
development is that short feedback loops enable the customer
(users) to experience the product sooner, which allows the
requirements and solutions to evolve during the execution of the
project. As Scrum is the most dominant agile software
development method nowadays, this paper is primarily focused
on this method and the concepts and terminology of Scrum are
used in the text.
1. The development of a specific set of requirements in a
specific period of time. Although executed in an iterative way,
the project has a ‘goal’, and at one point it is decided that the
project is finished. The product owner controls the project,
making sure that the necessary functionality is delivered within
time and budget.
In traditional approaches, this type of development would be
called a ‘New development project’ or a ‘release’;
2. The continued development (evolving) of an
application. In this situation there is no definite duration or a
specific set of user requirements. A year is divided into X sprints
of Y weeks and the team is continuously working on the product
backlog items the product owner deems the most important until,
it is decided that the product does not need further maintenance
(which may be in the far future).
In traditional approaches, this type of development would be
called ‘Maintenance’.
2. Productivity measurement of the contract type listed as
number 1, is not significantly different in agile projects than in
traditional projects. In both approaches, the difficulty lies in
measuring all functional changes properly in order to measure
the actual project size.
The focus of this paper is on the contract type described
under number 2. A team is working for an indefinite period of
time, which is divided into sprints of 2, 3 or 4 weeks length each,
on a product backlog. The product backlog is prioritized in such
a way that the product backlog items (PBI’s) with the highest
importance are planned to be delivered first. The PBI’s are also
rated in story points, which are assigned in a team effort.
II. PRODUCTIVITY MEASUREMENT IN TRADITIONAL
SOFTWARE PROJECTS
Productivity measurement in traditional software
development projects is quite straightforward [1]. The customer
and the supplier have to agree on a few items beforehand, the
most important being:
Which (variant of which) size measurement method to
use;
Which performance metrics to use;
Which activities are in scope and which activities are
out of scope for the performance measurement;
Which are the benchmarks or targets to use per metric;
Who is measuring, who is reviewing, how to deal with
differences of opinion.
To give an example, let’s look at a performance
measurement contract that a government agency and a supplier
used to measure the performance in a specific Java development
project with an indicative size of around 400 Nesma [2] function
points (FP). The items above were addressed in the following
way:
Size measurement: Estimated Nesma [3] ;
Performance metrics:
o Productivity: PDR (h/FP);
o Functional Quality: Defects/FP Acceptance
Test + 1st month production;
o Delivery Speed: FP per calendar month.
Activities in scope: Technical design, Coding,
Programmer test, System test, Support acceptance test,
Project management, Quality assurance;
Activities out of scope: Functional design, delivery
management, acceptance test, implementation;
Benchmarks targets: A relevant subset from the ISBSG
repository New Developments & Enhancements [4]
(e.g. Java projects, Government, size between 300 and
500 FP)
o PDR: ISBSG subset median PDR;
o Defects/FP: ISBSG subset percentile 25%;
o Speed of deliver: ISBSG subset median PDR.
The supplier measures the functional size, the customer
reviews the size measurement. The metrics can be
audited by the customer periodically. Independent third
parties may be used to solve differences of opinion.
Because of the specific set of requirements and the fact that
the goal of the project is clear (to realize that specific set of
requirements), the performance measurement is pretty
straightforward. As it is a Java development project for a
government agency, it is easy to select a proper subset from the
ISBSG repository to set the targets and benchmarks for this
project. If there are specific non-functional requirements that are
expected to have a significant influence on the performance, the
benchmarks and targets may need to be re-evaluated and agreed
upon.
After the project has finished, the project size is determined,
the performance metrics are calculated and it becomes clear if
the performance targets are met or not..
III. WHY ARE AGILE PROJECTS DIFFERENT?
Most people in the software industry know the four main
principles of the agile manifesto [5]:
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan.
Although the items on the right of the word ‘over’ are still
important, the items on the left are considered more important.
In practice, an agile project can be described in the following
general way:
A very important role is played by the product owner, who
is a representative of the customer/user organization. This
product owner needs to be knowledgeable about the
functionality of the product and the business value it offers to
the users. Also, the product owner needs to have a mandate from
the customer organization to make decisions and he needs to be
committed to fulfill his role. This means that he is able to devote
the time needed to carry out his role, this means that he is able
to meet with the team when necessary, make decisions when
necessary and prioritize the backlog items by business value.
There is a product backlog available which lists the product
backlog items identified by the product owner. These backlog
items are either functional or non-functional by nature. The
effort needed to realize the product backlog items are estimated
by the team members using story points. Although many people
in the agile community think the story point measure is a size
measure, it is in fact an effort measure. It is a relative measure
which gives an estimate of how many hours the team thinks they
need to spend on a particular product backlog item, compared to
3. a specific baseline backlog item to which a random number of
story points was assigned. There is no standard approach for
assigning story points. Most teams identify the smallest product
backlog item in the product backlog and assign 1, 2 or 3 story
points to it. All other backlog items are then compared to this
baseline backlog item and the number of story points assigned
to them reflect the effort the team needs to realize them,
compared to the baseline item. This method is absolutely
subjective and probably not very repeatable or verifiable.
Although story points are quite useful for sprint planning, as
to decide which product backlog items can be realized in a
specific sprint, metrics based on story points are completely
useless for performance measurement. As there is no standard
for assigning story points (it is not a measurement activity), it is
quite easy to manipulate the amount of story points realized in a
sprint in order to comply to the targets set. And since there is no
reference point, it is easy to manipulate the targets as well.
But still, organizations wish, and sometimes need, to
measure the performance of their suppliers, also in agile
executed projects. In many cases the usual performance metrics
are agreed upon, but instead of using a project or a release as a
basis for measurement, the performance measurement
instrument is applied to sprints. This means that for every sprint,
the functional size delivered should be measured, the effort
hours in scope need to be retrieved, the defects found and
resolved must be identified and the performance metrics should
be calculated. Some issues, when not properly addressed,
already arise here:
Agile teams don’t usually register defects. Especially
not when they are easy to resolve;
Agile teams are multidisciplinary by nature. Sometimes
it is hard for the team members to register their effort on
specific tasks. This is important however, as some tasks
may be out of scope for performance measurement;
Agile teams sometimes don’t change the functional
documentation in the same sprint where the
functionality is realized in. This makes it difficult to
measure the functional size of that sprint;
According to the theory, at the end of each sprint,
working software is delivered that could be
implemented in a production environment. In practice,
this is not always the case and product backlog items are
declared “not ready” at the end of the sprint. As only
functionality that is ready is measured, this means a low
size delivered in that sprint and possibly a relatively
high size delivered in the next sprint.
The product owner decides which product backlog items are
the most important. Here, the main issue comes to light. The
product owner may decide that mainly non-functional backlog
items need to be realized in a specific sprint. As functional size
measurement methods only measure the functional user
requirements, a size measurement of such a sprint would result
in a few (or even zero) function points. In these cases, the usual
performance metrics result in bad values and targets are not met
for that sprint.
So, there is a number of issues when trying to implement the
traditional performance measurement instrument on sprint level
in agile contracts. Summarized these issues are:
The functional size of the delivered product can be hard
to measure, either because of under specification, or
because the documentation provided does not reflect the
status of the product after the sprint;
The effort hours are not booked consciously on the right
tasks in the effort registration system, making it hard to
define the number of hours spent on the activities in
scope of the performance measurement;
During the sprint, system tests and acceptance tests are
carried out, but defects found and defects resolved are
not logged appropriately, making it hard to use the
quality metrics.
The functional size delivered in a sprint may be very low
(or zero), seriously affecting the performance metrics.
Reasons for this could be (not limitative):
o The product backlog items turned out to be
too big to deliver in a sprint and were not ready;
o Illness of team members or other unplanned
events that may have disturbed productivity;
o Non-functional backlog items to realize in the
sprint (e.g. improving performance, security, code
quality, et cetera).Finally, complete content and
organizational editing before formatting. Please take note
of the following items when proofreading spelling and
grammar:
These issues result in very uneven performance metrics over
time. An example of how this could look like is given below for
the PDR. Let’s say the following data is measured for 8 sprints
(table 1).
Sprint 1 2 3 4 5 6 7 8
Effort 345 389 367 412 365 375 390 401
Size (FP) 15 5 16 3 25 0 36 32
Table 1
This would result in the following PDR per sprint (table 2).
Sprint 1 2 3 4 5 6 7 8
PDR
(h/FP)
23,0 77,8 22,9 137,3 14,6 n/a 10,8 12,5
Table 2
In sprint 6 zero function points were realized, so it is
impossible to determine the PDR in h/FP. Let’s assume the
target PDR for the specific project is set to be 25,0 hours per
function point, the performance graph would look like in figure
1.
4. Fig. 1. PDR actual vs. target
The productivity realized shows a very uneven view. In the
next paragraph a method is proposed that should give better
insight into the suppliers capabilities and performance.
An option to overcome the issues mentioned would be to
only use the effort hours spent on functional backlog items for
the performance measurement. In practice, it is very hard to
identify these effort hours. Furthermore, this approach makes it
easy to manipulate the performance measurement simply by
booking more hours on non-functional backlog items (assuming
that there is no control on the effort hours booked). Instead of
normalizing the effort hours to match the functional size, the
method proposed in this paper is to normalize the functional size
to match the total effort.
IV. PROPOSED METHOD
The performance measurement method that is proposed in
this paper is to normalize the functional size in order to
determine the functional size that the team could have realized
if they would not have been instructed to realize any non-
functional backlog items.
This method enables organizations to use the standard
methods and techniques for performance measurement and
benchmarking , while almost no extra data or effort is necessary.
The method is not totally objective, but possibilities of
manipulation (consciously or unconsciously) are very limited.
In order to carry out this normalization activity, one extra
activity needs to be performed. The Scrum team assigns story
points to the backlog items, so the number of story points that is
realized in a specific sprint is known. Of each of the sprint
backlog items, the team should decide if the nature of the item
is (mainly) functional or non-functional. The ratio between the
functional and the non-functional story points is used to
normalize the functional size.
Examples of functional backlog items could be: Add a field
to the database table ‘User’ named ‘twitter username’, add a
field to the ‘manage user’ screen in which the administrator can
enter the ‘twitter username’ and Add a twitter icon to the screen
if the user has a ‘twitter username, linking to user’s twitter page.
Examples of non-functional backlog items could be:
Improve the performance of the batch job in order to have it run
in under 2 hours, Improve the code quality of the application to
be to compliant to SQALE rating A [6] or Upgrade the
development environment to the next version, because the
supplier stops supporting the current version any time soon’
The proposed method contains the following steps:
1. Measure the functional size of the functional sprint
backlog items that were ready at the end of the sprint
using one of the mentioned ISO/IEC standards for
functional sizing;
2. Determine for all sprint backlog items that were ready
at the end of the sprint, if these were functional or non-
functional by nature. In case of a hybrid nature, try to
assess the ratio functional/non-functional;
3. Determine the number of story points that were
assigned to the functional backlog items that were
ready at the end of the sprint;
4. Determine the total number of story points that were
assigned to all backlog items that were ready at the end
of the sprint;
5. Calculate the Agile Normalized Size (ANS) using this
formula:
ANS = (functional size / functional story points) *
total story points
Example: In a sprint, five backlog items were realized (see
table 3). Three of them are functional by nature, the other two
non-functional. The functional size of the functional backlog
items is measured using Nesma function point analysis.
Sprint X Nature Nesma FP Story points
BLI 1 Functional 4 4
BLI 2 Non-functional 0 6
BLI 3 Non-functional 0 2
BLI 4 Functional 5 3
BLI 5 Functional 4 3
Total 13 18
Table 3
The ANS in this example is: (13 / 10) * 18 = 23,4 FP. The
ANS represents the equivalent of the functional size that could
have been realized if only functional backlog items would have
been included in the sprint.
0,0
20,0
40,0
60,0
80,0
100,0
120,0
140,0
160,0
3 4 5 6 7 8 9 10
PDR (h/FP) Target PDR (h/FP)
5. In table 4, it is displayed that the ANS gives a more accurate
view of the size in sprints in which a lot of non-functional
backlog items were realized. This is especially obvious in sprint
4:
Table 4
Advantages of this method
The main advantage of this method is that the influence of
the non-functional backlog items is reduced, while still an
ISO/IEC standard method is used in order to determine the
functional size. This productivity can then be compared with
data that is measured using the same (type of) ISO/IEC standard
method.
Disadvantages of this method
The method is dependent on the story points assigned to the
functional and non-functional backlog items. Assigning story
points, as indicated before, is a highly subjective activity.
However, as it is a necessary activity carried out before the
actual start of the sprint and because of the fact that the product
owner is usually present to oversee this activity, chances of the
team manipulating the assigning of the story points are
considered to be small. Also, for the determination of the nature
of the backlog items, there is no standard approach, but usually
it should be easy to understand if backlog items are functional or
non-functional by nature. One other disadvantage of the method
is that it is impossible to measure the ANS if only non-functional
backlog items are realized in a specific sprint. In section V The
Progressive Approach, this issue is solved.
Effort hours in scope of performance measurement
It is always important to carefully consider the effort hours
that should be taken in scope of the performance measurement.
Usually, the benchmark used determines the effort hours that are
in scope, as you wish to compare apples with apples. If, for
instance, the benchmark used is based on a project lifecycle
excluding functional design and overhead hours, the effort hours
spent on these activities should be placed out of scope for the
performance measurement.
Due to the fact that in the proposed method the size is
normalized, all activities that are carried out to realize any
backlog item, functional or non-functional, have to be in scope
for performance measurement. This would mean activities like
(not limitative):
Design (functional and/or technical);
Coding and programmer test;
System test;
Scrum master;
Project support (for the Scrum master);
Create/adjust documentation;
Resolving defects;
Research (proof of concepts et cetera);
Meetings / sessions.
Effort hours spent on activities that are not directly related to
realizing backlog items are out of scope for performance
measurement, e.g.:
Delivery management;
Quality Management;
Project support (for the delivery management).
After the effort hours in scope have been determined, the
productivity per normalized FP can be calculated, see the
example in table 5:
Table 5
In the figure 2 it is clear that the hours/nFP metric provides
a more stable view than the hours/FP metric. The fact that
development of new functionality is not the most important goal
is normalized into a situation where it is.
Sprint
Func.
size
Functional
story
points
Non-
functional
story points
Total
story
points ANS
1 20 32 12 44 27,5
2 25 y28 16 44 39,3
3 18 24 20 44 33
4 29 35 4 39 32,3
5 4 6 36 42 28
6 15 16 24 40 37,5
Sprint
Func.
size (FP)
Agile
normalized
size (nFP)
Effort
spent
Hours/
FP
Hours
/nFP
1 20 27,5 500 25 18,2
2 25 39,3 480 19,2 12,2
3 18 33 530 29,4 16,1
4 29 32,3 468 16,1 14,5
5 4 28 534 133,5 19,1
6 15 37,5 522 34,8 13,9
6. Fig. 2. Hours/FP vs. Hours per nFP
V. THE PROGRESSIVE APPROACH
One of the aforementioned disadvantages of the proposed
method is that it’s not possible to determine the normalized size
for sprints in which no functional backlog items were realized.
This can be obviated by using the progressive approach.
The progressive approach divides the sum of the functional
sizes of all completed sprints by the sum of the functional story
points of these sprints. The result hereof is then multiplied with
the sum of all story points of all completed sprints. This
approach makes it possible to take sprints into account in which
no functional backlog items were realized. In table 6, the
example used earlier has been elaborated to explain the
progressive approach:
Sprint
Functionalsize(FP)
Functionalstorypoints
Non-functionalstorypoints
Totalstorypoints
Agilenormalizedsize(nFP)
Hours/nFP
Hoursspent(cumulative)
ANS(progressive)
Hours(cum)/nFP(progressive)
1 20 32 12 44 27,5 18,2 500 27,5 18,2
2 25 28 16 44 39,3 12,2 980 66 14,8
3 18 24 20 44 33 16,1 1.510 99 15,3
4 29 35 4 39 32,3 14,5 1.978 132,2 15
5 4 6 36 42 28 19,1 2.512 163,6 15,4
6 15 16 24 40 37,5 13,9 3.034 199,2 15,2
7 0 0 41 41 n/a n/a 3.546 231,4 15,3
8 18 24 20 44 33 15,4 4.054 264,3 15,3
Table 6
The productivity expressed in hours/nFP and the
productivity in hours (cum)/ nFP(progressive) can be
benchmarked against the traditional internal and external
hours/FP benchmarks, like for instance the ‘New Developments
and Enhancements repository of the International Software
Benchmarking Standards Group [4].
In the figure 3, the figures from the example are shown. The
benchmark PDR in this example is set on 20 hours/FP.
Fig. 3. The progressive apprach results
The main benefits of the proposed method are clearly
visible in sprints 5 (in which mainly non-functional backlog
items were realized) and 7 (in which only non-functional
backlog items were realized).
Starting points
In order to use the proposed method in the proper way, a
number of starting points have to be taken into account.
Effort administration
The effort hours need to be booked in the effort
administration in such a way that it is possible to
clearly identify the effort hours in scope and out of
scope of the performance measurement;
All effort hours spent on the project must be booked,
also overtime;
Hours spent on other projects should not be booked on
the project that is being measured;
The team members need to understand the importance
of an accurate and correct time administration.
Documentation
After each sprint the functional documentation should
be made up-to-date and it must be clear:
o Which functionality was added in the sprint;
7. o Which functionality was changed in the sprint
and in which way;
o Which functionality was deleted in the sprint.
Size Measurement
The effort hours need to be booked in the effort
administration in such a way that it is possible to
clearly identify the effort hours in scope and out of
scope of the performance measurement
Product backlog and sprint backlog
The product backlog consists of functional and non-
functional backlog items. For each item it is known
which type it concerns;
All items have been assigned story points to in a
realistic way;
The product owner decides which product backlog
items will be placed on the sprint backlog of the
sprints;
After each sprint it is decided which backlog items are
ready (meet the definition of done1
) and which items
are not (or not completely);
Data collection
After each sprint, a data collection form (DCF) must be
filled in by the Scrum master. In this DCF at least the
following information must be filled in:
o the effort hours per activity;
o the backlog items declared ready and their
associated type;
o the story points assigned to these backlog
items.
Performance Measurement
The productivity is determined using the method
described above;
The functional size, the data and the results of the
productivity measurement is stored in a central
location;
Standard reports are created in which the productivity
measurement is shown and compared to predefined
internal and external benchmarks. Also trends in
productivity within the projects are reported.
VI. CONCLUSIONS
More and more organizations adopt agile software
development methodologies to deliver new functionality in a
faster way to their customer. In the meantime, in the slowly
maturing software industry, the need for productivity
measurement is becoming more and more important, especially
in outsourcing contracts. As long as the most important
objective of agile projects remains delivering new or changed
functionality, the traditional productivity measurement
instruments can still be used in an effective way. In projects, or
contracts, that are mainly about evolving a certain application,
without a specific end date or a specific scope, the productivity
is sometimes hard to measure in ISO/IEC standards for
functional size measurements. The influence of non-functional
requirements can really impact the productivity and the product
owner (customer) is the only one who can control this. Some
attempts have been made in the recent past to normalize the
effort hours in order to capture only effort hours that were spent
on functional user requirements. However, in practice it seems
impossible to do so. Instead, this paper proposes to normalize
the functional size in such a way that the functional size is
calculated that could have been realized in a sprint if the product
owner only put functional backlog items on the sprint backlog.
Whether this method really is going to solve all the issues in
productivity measurement of agile projects still has to be
proven.
REFERENCES
[1] Bundshuh, M. and Dekkers, C, The IT Measurement Compendium,
Estimating and benchmarking success with functional size measurement,
page 313, Spinger, ISBN: 978-3-540-68187-8
[2] NESMA: ISO/IEC 24570:2005 Software engineering - NESMA function
size measurement method version 2.1 - Definitions and counting
guidelines for the application of Function Point Analysis, ISBN: 978-90-
76258-19-5
[3] Early Function Point Counting, http://nesma.org/themes/sizing/function-
point-analysis/early-function-point-counting/
[4] International Software Benchmarking Standards Group (ISBSG) New
Developments & enhancements R13, released February 22015,
www.isbsg.org
[5] Beck, Kent et al. (2001). "Manifesto for Agile Software Development".
Agile Alliance. Retrieved 14 June 2010
[6] Letouzey, J-L, The SQALE Method for Evaluating Technical Debt,
proceedings of the 3rd
international workshop on managing technical debt
(ICSE 2012), Zurich (Switzerland) june 9-12 2012.
1
The Definition of done is determined before the start of an
agile project. Only if all characteristics of that definition have
been met, the item is considered ‘ready’.