Using the COSMIC method to estimate Agile user stories

Transcription

1 Using the COSMIC method to estimate Agile user stories University of Utrecht Graduate School of Natural Sciences Department of information and computing sciences Date : Course : Method Engineering Course code : INFOME Version : Final TA : Daniel Alami Assignment : D Lody Koop l.koop@students.uu.nl

2 Table of Contents 1. Introduction Example PDD PDD DIAGRAM Activity Table Table of Concepts Related Literature References

3 1. Introduction This paper elaborates the estimation of agile user stories by using the COSMIC method, described by Desharnais, Buglione, and Kocatürk (2011). Agile product management (APM) is nowadays the leading method to engage software projects. APM is based on the Agile Manifesto (Schwaber, 2004). Following the manifesto, APM leads to better handling of uncertainty and unpredictability of requirements in a product lifetime. In the agile way of working the requirements are often depicted by user stories (US) (Cohn, 2004). An US is a product requirement captured in one sentence following a strict format. When planning the software project, the amount of effort needed to implement the US is estimated. Nowadays, most agile teams use the Planning Poker technique (Haugen, 2006; Mahnič & Hovelja, 2012). This technique is an easy, low-level estimation where different software developers give their own opinion about the US implementation effort. The advantages of Planning Poker are that it is easy to do and requires little time. Furthermore, when software developers disagree on estimated implementation effort this will immediately lead to a discussion about the US. However, besides these advantages, Planning Poker is still a guess estimation and therefore unreliable. Desharnais et al. (2011) argue for a better estimation technique than the commonly used Planning Poker. They plead for using the COSMIC method instead. The COSMIC method conforms the ISO/IEC JTC1/SC7 standard and is a software sizing technique. The method ascribes functional size to every US by using COSMIC function points (CFP). By doing this, it realizes a standardized estimation approach which is not present in Planning Poker. More advantages of COSMIC relative to Planning Poker are that it not only estimates the software size of the requirements in the beginning of the project, but also tracks requirements as they evolve in the project. Furthermore, it computes the project performance parameters when the project is delivered. Estimating US using the COSMIC method happens in the following procedure: 1. Get user requirements for each US 2. Discussion on user requirements formulation by developers to find functional processes 3. Determine the size of each US by using COSMIC method (CFP) 4. Discussion on calculation effort per CFP per US 5. Calculation total number of hours by multiplying CFP by Effort/CFP 6. Prepare first project plan according to the calculated effort values 7. Prepare second round (if necessary third round) of planning, using new information As can be concluded from the seventh step, the procedure is an iterative process which improves every time undertaken. The deliverables of the first phase are well documented US. The second phase adds formulation of the US in terms of technical implementation. The third phase ascribes CFPs to every US. This happens by looking at all the different data movements an US (functional process) triggers. There are four different types of data movements. Entry and Exit data movements are data groups which are moved between the functional user (the actor that communicates with the functional process) and the functional process. Read and Write data movements are data groups which are retreived from or written to a persistant storage (e.g. a database). After all data movements required by a functional process are discovered, the software architect can subtract the already implemented data movements from this set of required data movements. The data movements which are left are the number of CFPs per US. After the CFPs per US are known, the deliverable is enriched with effort per CFP. This is done by using the expertise and experience of the development team and software architect and if possible by consulting a database with benchmarks of similar projects and US. This process is done during the fourth phase. Subsequently, the fifth fase consists of calculating the total amount of project man-hours by multiplying the CFPs with the corresponding effort per CFP. The sixth phase uses the documentation and knowledge from the former phases and creates the project planning as a deliverable. The name of the COSMIC method stands for its creators. COSMIC stands for the Common Software Measurement International Consortium. This is an international group of software measurement experts which is founded in This group created COSMIC because they believed big improvements could be made in traditional function point methods. The appliance of the COSMIC method on US in an agile way of working is proposed by Desharnais et al. (2011). Desharnais and Buglione are associate proffesors at the École de Technologie Supérieure. 3

4 2. Example This example is partly based on the article: Using the COSMIC method to estimate agile user stories by Desharnais et al. (2011). A library wants to create a new software system for renting books. They hire a software production which works according the agile manifesto. However, instead of the usual planning poker technique the company needs a more accurate technique of software sizing and makes use of the COSMIC method. The following example elaborates on the steps the software company undertakes to create the project planning for creating the book rental system. 1. The development team is going to interview the library to obtain functional and qualitative requirements. The formulation of functional requirements follows a strict US template. The formulation of US starts at a high abstract level. 2. When the process develops these high level US will be broken down by developers (if required in cooperation with the librarians) in low level specific US. For example, when the requirement captured in a high level US is: As a librarian, I want to manage customer data., this can be broken down in smaller atomic US such as: As a librarian, I want to add new customers, so that new customers can join the library. These low level US will represent functional processes which are elementary components of a set of functional user requirements. These low level US are now ready for getting functional points ascribed using the COSMIC method. The US after step 2 can be found in figure 1 in the User Story column. After this, the product manager has the possibility to prioritize the US in order to deal with urgent US first. However, the prioritizing of US is outside the scope of this paper. 3. The development team will ascribe CFPs to every US by using the COSMIC method. An US such as As a librarian, I want to add new customers, so that new customers can join the library. is estmated in the following steps. First, the development team identifies the functional user (librarian). Subsequently, the team estimates the data groups and data movements. Information about the customer (name, age, adress, contact, etc) and information about the customer s subscription (price, date of expiry, etc) is required. Therefore, there are two data groups. When a functional user enters the data, two data entry movements are needed. The system s functional process needs to read the database and write the database which results in two read and two write data movements. The functional process should also be able to return these two data groups to the functional user plus an error message if necessary. This results in three exit data movements. The total of required data movements is nine (2 entry, 2 read, 2 write, 3 exit). Considering the fact that the development team is in a greenfield situation, all data movements need to be implemented. Ergo, the number of estimated CFPs for this US is also nine. The calculated CFPs are shown in the CFP column in figure After the CFPs are calculated for all US, the team will determine the effort per CFP. This will be done by benchmarking. The software development team uses an historical project database for the benchmarking and takes potential influences not covered by the historical project database into account. Once the team reaches an overall agreement, the effort per CFP is added to the document. The results of this step can be found in the Effort per CFP column in figure The fifth phase is trivial and holds the multiplying of the effort per CFP with the total amount of CFPs. This will give the estimated hours per US together with the total project estimation and is depicted in the last column of figure The deliverable of the first 5 phases (figure 1) will guide the scrum master in making a proper planning for the sprints. The deliverable after this step is the project planning for making the library software system. 7. The former six phases are an iterative process and can be repeated for multiple times. Every time the process repeats, the CFPs ascribed to US can be adjusted together with the estimated effort per CFP. 4

5 Figure 1. 5

6 3. PDD This section describes the application of the COSMIC method for User Story estimation (US) in an agile context. For analyzing, communication and creating methods we avail ourselves of the method engineering domain. Method engineering is defined as: the engineering discipline to design, construct and adapt methods, techniques and tools for the development of information systems. (Brinkkemper, 1996). The standard notation in this domain introduced by Weerd and Brinkkemper (2008) is the Process-Deliverable Diagram (PDD). The PDD consists of two main elements. The left side of the PDD holds the activities executed during the method. The right side of the PDD shows the deliverables (concepts) produced by fulfilling the activities on the left hand side. The PDD syntax is based on the Unified Modelling Language. For further syntax one should consult the paper of Weerd and Brinkkemper (2008). Furthermore, all activities and concepts are elaborated in the activity table and table of concepts. Different fragments from different methods can be merged, the analysis for this can be done by using the PDD notation. Please note that the roles ascribed to activities are example roles and can be fulfilled by similar functions in a specific business environment. As mentioned above, this document merges the application of the COSMIC method with a standard agile approach which uses US to capture requirements. The blue parts of the PDD diagram consist of the standard activities for software planning in an agile way. The purple part consists of the COSMIC method. Normally, this method fragment would be filled by a planning technique such as a Planning Poker (Haugen, 2006; Mahnič & Hovelja, 2012). However, in the method proposed by Desharnais, Buglione, and Kocatürk (2011), the Planning Poker is replaced with the COSMIC method. The US engineering fragment consist of all the activities done for capturing, formalizing and prioritizing US for implementation (Cohn, 2004). This is often done by a product manager/owner. The activity fragment named Determine every User Story size with COSMIC ascribes COSMIC Function Points (CFP) to every US. CFPs are based on the amount of data movements a US needs to fulfill in order to be successfully implemented. To do this, a triggering event, functional user(s), functional processes and data groups need to be identified. After summarizing all different categories of data movements the architect checks which data movements are already implemented in the software and which are not. The data movements which are not implemented are exactly one CFP. After the CFPs per US are known for all US the development team and software architect estimate the effort per CFP expressed in hours per CFP. If a project database is available containing information about similar projects the team can use this to create a benchmark estimate. If there is no information available about previous projects the team should estimate the CFPs with only their experience and expertise. When the total man-hours per US are known, the product manager and software architect can create the project planning and ascribe teams to specific US. Subsequently, the teams will realize the estimated US. After every implementation phase, parts of the process can be repeated for optimizing future project planning. For example, when new knowledge is acquired during the execution of the project, the development team can adjust the estimated effort per US and facilitate the creation of a more accurate project planning. The Gather requirements, Prioritize US, Make project planning and Execute project phase activities are modelled as closed activities since the exact manner of execution is not relevant in the context of estimating agile US using the COSMIC method. The purpose of these activities is to clarify the total process. Correspondingly, the exact properties of the Project Planning and Project Deliverable are not relevant in the context of this paper. 6

7 4. PDD DIAGRAM 7

8 5. Activity Table 6. Activity Sub-Activity Description US Engineering Gather Requirements Several functional REQUIREMENTS are gathered from all relevant system stakeholders. The specific techniques in which this activity is executed is not relevant in the context of this paper. Determine every user story size with COSMIC (All sub activities are performed by the software architect and development team.) Transform requirements to high level US Decompose high level US into atomic US Prioritize US Identify triggering event Identify functional users REQUIREMENTS can be captured in a strict format called USER STORIES. This activity is performed by the product manager. HIGH LEVEL USER STORIES can be composed in LOW LEVEL USER STORIES. This is done by extracting smaller functionality fragments out of the HIGH LEVEL USER STORIES until this is no longer possible. This activity is performed by the product manager, sometimes in cooperation with the software architect. Before further analysis, prioritizing USER STORIES is important. This will be done to optimize the project s cost/benefits. The product manager will assign a specific PRIORITY to every USER STORY which holds a rationale. The specific techniques to execute this activity is not important in the context of this paper. The identification of the separate events in the world of the FUNCTIONAL USERS that the software must respond to. The identification of which FUNCTIONAL USERS of the software must respond to each TRIGGERING EVENT by generating a DATA GROUP that is moved by a triggering ENTRY. Identify functional process for each triggering event The identification of one FUNCTIONAL PROCESS for each triggering ENTRY. Identify data groups The identification of all relevant DATA GROUPS which are moved by a related FUNCTIONAL PROCESS. Identify all other entry data movements The identification of any other ENTRIES and all the EXITS, READS and WRITES of each FUNCTIONAL PROCESS which are needed to meet the functional REQUIREMENTS for all possible responses to the triggering ENTRY. Identify all read data movements The identification of all READ DATA MOVEMENTS. Identify all write data movements The identification of all WRITE DATA MOVEMENTS. Identify all exit data movements The identification of all EXIT DATA MOVEMENTS. Summarize data movements per US All identified DATA MOVEMENTS are stated in the DATA MOVEMENT TABLE. Estimate CFP The CFPs can now be estimated per US. This is done by extracting all non-implemented DATA MOVEMENTS from the DATA MOVEMENT TABLE. This amount of non-implemented DATA MOVEMENTS is the number of CFP PER US. Estimate Effort Consult project Database If a project database is available, the development team should consult the database for benchmarking the project. Filter on project characteristics After opening the database, the development team will compare the current project with succeeded projects. After doing this the team can draw a BENCHMARK ESTIMATE. 8

9 Estimate effort per CFP Calculate man-hours per US Calculate total project man-hours Make project planning Execute project phase If the development team had access to a projects database, it can use the BENCHMARK ESTIMATE and experience to ascribe EFFORT PER CFP for every single US. If the development team does not have access to a projects database, the team can only do the estimation based on the experience of the team members. The MAN-HOURS PER US are calculated by multiplying the EFFORT PER CFP with CFP PER US. This activity is performed by the software architect. The PROJECT MAN-HOURS TABLE is created where all US now have a required time estimation and which also holds the total project man-hours estimation. This activity is performed by the software architect. The creation of the PROJECT PLANNING, executed by a product manager or software architect. The specific execution of this activity is not relevant in the context of this paper. The designated time where a software development team will realize the REQUIREMENTS assigned to it. The specific execution of this activity is not relevant in the context of this paper. 9

10 7. Table of Concepts Concept Description REQUIREMENT An REQUIREMENT holds a condition or capability need by a user to solve a problem or achieve an objective (IEEE, 1990). The REQUIREMENTs in the document also include an identifier and description. REQUIREMENT LIST A document where al REQUIREMENTS are listed. US An USER STORY is a short, simple description of a desired feature told from the software user perspective. It typically holds a role (software user), goal, and desired benefit (Cohn, 2004). USER STORIES are also marked with an ID. HIGH LEVEL US A HIGH LEVEL USER STORY is a low detail category of USER STORIES (Cohn, 2004). HIGH LEVEL USER STORIES are often referred to as Epics. LOW LEVEL US The LOW LEVEL USER STORY can not be decomposed in a smaller piece of desired functionality (Cohn, 2004). LOW LEVEL USER STORIES are often referred to as Atomic User Stories. US LIST A document where al USER STORIES are listed. PRIORITY PRIORITY refers to the level of importance assigned to a REQUIREMENT (ISO/IEC/IEEE, 2010). Every PRIORITY should hold a rationale concerning the ascribed level. TRIGGERING EVENT An event that causes a FUNCTIONAL USER of the piece of software to initiate ( trigger ) one or more functional processes (ISO/IEC, 2011). FUNCTIONAL USER The FUNCTIONAL USER is a sender and/or an intended recipient of data in the Functional User Requirements of a piece of software (ISO/IEC, 2011). FUNCTIONAL A FUNCTIONAL PROCESS is elementary component of a set of Functional User PROCESS Requirements, comprising a unique, cohesive and independently executable set of DATA MOVEMENTS (ISO/IEC, 2011). DATA GROUP A DATA GROUP is a distinct, non empty, non ordered and non redundant set of data attributes where each included data attribute describes a complementary aspect of the same object of interest (ISO/IEC, 2011). DATA MOVEMENT The movement of a single DATA GROUP (ISO/IEC, 2011). READ READ is a DATA MOVEMENT that moves a DATA GROUP from persistent storage within reach of the FUNCTIONAL PROCESS which requires it (ISO/IEC, 2011). EXIT EXIT is a DATA MOVEMENT that moves a DATA GROUP from a FUNCTIONAL PROCESS across the boundary to the FUNCTIONAL USER that requires it (ISO/IEC, 2011). ENTRY ENTRY is a DATA MOVEMENT that moves a DATA GROUP from a FUNCTIONAL USER across the software boundary into the FUNCTIONAL PROCESS where it is required (ISO/IEC, 2011). WRITE WRITE is a DATA MOVEMENT that moves a DATA GROUP lying inside the DATA MOVEMENT TABLE CFP PER US BENCHMARK ESTIMATE EFFORT PER CFP MAN-HOURS PER US FUNCTIONAL PROCESS to persistent storage (ISO/IEC, 2011). A document where the relation between DATAGROUPS, DATA MOVEMENTS and FUNCTIONAL PROCESSES is depicted. Furthermore, it contains the total of data movements per US and the US identifiers. The amount of estimated COSMIC FUNCTION POINTS PER US. This is the end result of the COSMIC method application (Desharnais, Buglione, & Kocatürk, 2011). The CFP PER US also holds the US specific identifiers. The BENCHMARK ESTIMATE is a result of comparing succeeded projects containing similar characteristics with the current project. The BENCHMARK ESTIMATE is a valuable source of information needed for the determination of EFFORT PER CFP (Desharnais, Buglione, & Kocatürk, 2011). The estimate holds information on similar succeeded US and has a rationale why the US are similar to the current project. The EFFORT PER CFP is determined by using the BENCHMARK ESTIMATE in conjunction with the developer s/architect s experience (Desharnais, Buglione, & Kocatürk, 2011). The effort is stated in terms of hours. A document where the estimated amount of man-hours for each USER STORY is stated. 10

11 PROJECT DELIVERABLE PROJECT MAN- HOURS TABLE PROJECT PLANNING A work product to be delivered to the acquirer (ISO/IEC/IEEE, 2010). A document where the relation between the prioritized USER STORIES and MAN-HOURS PER USER STORY are depicted. The document also holds the total of man-hours and a project ID. The specific properties of this concept is not relevant in the context of this paper. The activities concerned with the specification of the components, timing, resources, and procedures of a project (ISO/IEC/IEEE, 2010). The specific properties of this concept is not relevant in the context of this paper. 11

12 8. Related Literature The COSMIC method descends from the Constructive Cost Model estimation model (COCOMO) (Boehm, 1981). COCOMO is an estimation technique which uses the project characteristics and compares this with historical data about software projects with similar characteristics. The COSMIC method uses the main ideas of the COCOMO technique and is the first in its kind to be approved as an official ISO/IEC standard. The difference between COCOMO and COSMIC is that the former uses lines of code as a parameter, the latter replaces this with the functional size method (ISO/IEC, 2007). Significant research in cost modeling techniques started in the late sixties with the extensive SDC study of the 104 attributes of 169 software projects (Nelson, 1967). After this event several different cost estimation techniques started to develop such as SLIM (Putnam & Myers, 1991) and COCOMO. Boehm, Abts, and Chulani (2000) have summarized the leading techniques concerning software development estimation. They argue that no single technique is perfect for all situations. A widespread survey was conducted among several software developers. Unfortunately, the usage of COSMIC is only mentioned and not studied in this overview of approaches. A broader study in agile software estimation is conducted by Santana, Leoneo, Vasconcelos, and Gusmão (2011). In this study the relation between functional point estimation and US points (similar to planning poker) is examined. The study shows that both estimations are not related. Unfortunately, the study does not hold any information about the suitability of functional point estimation in an agile way of working. At the current moment, to the best of our knowledge, no case studies have been conducted in the context of applying the COSMIC method to agile US. Jayakumar and Abran (2013) compare different software estimation techniques in an industrial wide survey. They conclude that functional size-based techniques such as COSMIC are amenable to performance studies and benchmarking. In addition, these functional size-based techniques tend to have more accurate estimates than other technique types. Furthermore, the study shows that COSMIC method overcomes the limitations of first generation function point methods. Lavazza and del Bianco (2009) have conducted a case study whether the application of UML would benefit the COSMIC method process. The study shows that UML can be conveniently used to help build models that are relatively easy to measure using COSMIC rules. 12

13 9. References Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Information and Software Technology, 38(4), Boehm, B., Abts, C., & Chulani, S. (2000). Software development cost estimation approaches A survey. Annals of Software Engineering, 10(1), Boehm, B. W. (1981). Software Engineering Economics. Upper Saddle River, NJ, USA: Prentice Hall PTR. Cohn, M. (2004). User Stories Applied: For Agile Software Development. Redwood City, CA, USA: Addison Wesley Longman Publishing Co., Inc. Desharnais, J.-M., Buglione, L., & Kocatürk, B. (2011). Using the COSMIC method to estimate Agile user stories. Proceedings of the 12th International Conference on Product Focused Software Development and Process Improvement, Torre Canne, Brindisi, Italy, Haugen, N. C. (2006, July 2006). An empirical study of using planning poker for user story estimation. Proceedings of the conference on Agile 2006, Visegrád, Hungary, IEEE. (1990) IEEE Standard Glossary of Software Engineering Terminology. Piscataway, NJ, USA. ISO/IEC. (2007). ISO/IEC :2007: Information technology -- Software measurement -- Functional size measurement Part 1: Definition of concepts. Geneva, Switzerland: ISO/IEC. ISO/IEC/IEEE. (2010). ISO/IEC/IEEE 24765:2010: Systems and software engineering -- Vocabulary. Geneva, Switzerland: ISO/IEC/IEEE. ISO/IEC. (2011). ISO/IEC 19761:2011: Software engineering -- COSMIC: a functional size measurement method. Geneva, Switzerland: ISO/IEC. Jayakumar, K. R., & Abran, A. (2013). A Survey of Software Test Estimation Techniques. Journal of Software Engineering and Applications, 6(10), Schwaber, K. (2004). Agile project management with Scrum. Redmond, WA, USA: Microsoft press. Lavazza, L., & Bianco, V. (2009). A Case Study in COSMIC Functional Size Measurement: The Rice Cooker Revisited. In A. Abran, R. Braungarten, R. R. Dumke, J. J. Cuadrado-Gallego, & J. Brunekreef (Eds.), Software Process and Product Measurement: International Conferences IWSM 2009 and Mensura 2009 Amsterdam, The Netherlands, November 4-6, Proceedings (pp ). Berlin, Heidelberg: Springer Berlin Heidelberg. Mahnič, V., & Hovelja, T. (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), Nelson, E. A. (1967). Management handbook for the estimation of computer programming costs. Santa Monica, CA, USA: System Development Corp. Putnam, L. H., & Myers, W. (1991). Measures for Excellence: Reliable Software on Time, within Budget. Upper Saddle River, NJ, USA: Prentice Hall Professional Technical Reference. 13

14 Santana, C., Leoneo, F., Vasconcelos, A., & Gusmão, C. (2011). Using Function Points in Agile Projects. In A. Sillitti, O. Hazzan, E. Bache, & X. Albaladejo (Eds.), Agile Processes in Software Engineering and Extreme Programming: 12th International Conference, XP 2011, Madrid, Spain, May 10-13, Proceedings (pp ). Berlin, Heidelberg: Springer Berlin Heidelberg. Weerd, I., & Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M. R. Syed & S. N. Syed (Eds.), Handbook of research on modern systems analysis and design technologies and applications (pp ). Hershey, PA: Idea Group Publishing. 14