Use case point technique Tutorial

7.2 Use Case Point Simple Medium Complex and Planning Poker Techniques

Hello and welcome to Software Estimation course offered by Simplilearn. In the previous module, we discussed IFPUG (Read as if-pug) FPA and NESMA (Read as nes-ma) that are functional size measurement techniques widely used for sizing software projects. These techniques are effective in the case of typical application development and enhancement project. However, they fall short for projects like testing, production support, bug-fix, agile-oriented projects, etc. In this module, we will focus on Use Case Point, Simple-Medium-Complex, and Planning Poker techniques. Let us look at the agenda of this module in the next slide.

7.3 Agenda

In this module, we will first understand ‘Use Case Point technique’ – an algorithmic technique. We will then look at Simple-Medium-Complex technique. Finally, we will discuss Planning Poker which is an expert judgment technique used in agile projects. Let us start with the introduction of UCP technique in the next slide.

7.4 Introduction Use Case Point(UCP)Technique

In most object-oriented software productions, use cases are used to describe functional requirements. Gustav Karner of Objectory, which is now IBM’s Rational Software, wrote a diploma thesis on ‘Use Case Points’ in 1993. In this technique, the use cases are analyzed and the size of the software being developed is measured based on the analysis. This method is an extension of IFPUG FPA and other models based on FPA. Similar to FPA based models, in this technique the software requirements are dissected into use cases and each use case is further broken to measure its size individually. The most important ingredient of this technique, however, is the availability of use cases for the software being developed. In the next slide, we will be introduced to the concept of ‘use case’.

7.5 Use Case Introduction

As mentioned in the previous slide, use case is an effective means to analyze and represent software requirements. Use case driven development is a characteristic of process models and frameworks like IBM Rational Unified Process or RUP (Read as r-u-p), Unified Modeling Language or UML (Read as u-m-l), etc. The figure shown in the slide represents an UML diagram for a restaurant operation. Each of the scenarios within this figure can form a use case. For example, ‘Receiving an order’, ‘Serving Food’, etc. can be individual use cases. Basically, a use case represents the set of steps defining the interaction between an actor and the system. ‘Actor’ here can be a user or an external system that interacts with the system under development. Each of these use cases have a defined target or goal to be achieved. The actors, steps, and goals are the core components of a use case. The use case can also have attributes like exceptions, alternate paths, extensions, etc. In the next slide, we will discuss UCP steps.

7.6 UCP Steps

The prerequisite for UCP technique is the availability of clearly documented use cases which detail out all the functionalities of the application. The next step is to determine the Unadjusted Actor Weight or UAW which is basically the weighted average score of all the actors in the system, calculated based on their complexity. Then we need to determine the total Unadjusted Use Case Weight or UUCW, which is basically the weighted average score of all the use cases in the system, calculated based on their complexity. Once the UAW and UUCW are calculated, the Unadjusted Use Case Point or UUCP for the system is determined by adding UAW and UUCW. UUCP describes the unadjusted size of the functional user requirements in terms of use case points. Similar to GSCs in IFPUG FPA, there are two components in UCP to handle the application characteristics. These are Technical Complexity Factor or TCF and Environmental Complexity Factor or ECF. There are thirteen technical factors and eight environmental factors that are to be analyzed and rated to determine TCF and ECF respectively. The formula to calculate TCF and ECF are shown in the slide. Note that the factors, ‘Tfactor’ and ‘Efactor’, are determined by calculating the weighted score of the technical and environmental factors respectively. Finally, the Adjusted Use Case Point or AUCP for the application is determined by multiplying UUCP, TCF and ECF. AUCP represents the total use case point of the application being developed, after adjusting with technical and environmental considerations. Let us look at each of these steps in detail in the following slides. We will start with determining the Unadjusted Actor Weight in the next slide.

7.7 Determine Unadjusted Actor Weight(UAW)

The first step to determine the Unadjusted Actor Weight is to identify all the actors in the system and classify them as Simple, Average, and Complex. The guidelines for each of these categories need to be defined at project-level or organization-level. Each category is assigned a weight with ‘Simple’ having the lowest weight and ‘Complex’ having the highest weight. These weights are then multiplied with the number of actors in each category. Finally, these products are summed to derive the unadjusted actor weights. An example for determining UAW is showed in the slide. There are 3 Simple, 2 Average and 5 Complex actors in the system. Based on the weights shown in the slide, the unadjusted actor weight is determined as 22 UAWs. In the next slide, we will understand how Unadjusted Use Case Weight is determined.

7.8 Determine Unadjusted Use Case Weight(UUCW)

The first step in determining Unadjusted Use Case Weight includes identifying all the use cases in the system and classifying them as Simple, Average, and Complex. The guidelines for each of these categories need to be defined at project-level or organization-level. Each category is assigned a weight, with ‘Simple’ having the lowest weight and ‘Complex’ having the highest weight. These weights are then multiplied with the number of use cases in each category. Finally, these products are summed to derive the unadjusted use case weights. An example for determining UUCW is shown in the slide. There are 2 Simple, 3 Average and 4 Complex use cases in the system. Based on the weights shown in the slide, the Unadjusted Use Case Weight is determined as 100 UUCWs. In the next slide, we will discuss technical factors like TCF.

7.9 Technical Factors

To determine Technical Complexity Factor or TCF, Tfactor needs to be determined. Tfactor is derived by rating thirteen technical factors on a scale of zero to five and multiplying the rating with the weights assigned for each of the factors. The sum of these products is Tfactor. The Technical Complexity Factor is calculated with the formula, TCF = 0.6 + (0.01 * Tfactor). The thirteen technical factors are shown in the slide. Note that the weights of these factors should not be changed. As evident, some of the factors are similar to the general system characteristics of IFPUG FPA. Let us briefly cover each of the factors. Distributed system signifies the characteristics where the system is distributed across various user bases as opposed to being installed in a single location. This is typically high for over-the-shelf software products which can be distributed and used remotely by users. Performance objectives are basically the performance requirements of the application under development like response time, concurrent users, etc. If the system is supposed to handle high-performance requirements, this factor gets a high rating. End-user efficiency deals with how efficient the end-users are to use the application. If the end-users are efficient in understanding how to operate the application, this factor gets a high rating. Complex processing is rated high if there is complicated processing logic, calculation or algorithm in the system. Critical applications like stock trading, avionics and scientific applications usually get a high rating for this factor. Reusable code is rated high if there is a high percentage of reusable code in the system being developed. Easy to install is the characteristic of the application which signifies the ease to install the application in the target environment. If no technical understanding is required and the installation process is intuitive, this factor gets a high rating. Similar to ‘easy to install’, ‘easy to use’ signifies the characteristic of the application which is easy to use and requires less dependence on the expert to use the application. Portable is the characteristic which allows the application to be installed in multiple hardware configurations. If the application is supposed to work in multiple environments, this factor is rated high. ‘Easy to change’ factor signifies the maintainability aspect of the application. If the application has to be developed taking into account the need for easier changes in future, this factor is rated high. ‘Concurrent use’ helps to describe the ability of the application to operate when many users are simultaneously using the application. This factor is rated high if the application is supposed to be used by a vast user group concurrently. Security describes the ability of the application to establish a secure connection between the client and server, ensuring the integrity and confidentiality of user information being transmitted. If the application requires high security of the information being transmitted, this factor is rated high. Access for third parties signifies the requirement of the application being made available to third parties apart from the intended end users. This needs additional customizations in the application, specific to the third parties. If the application is required to be customized and used by third-party stakeholders, this factor is rated high. Finally, training needs signify the requirement of training the end users of the application. If a large user base is supposed to be trained on using the application, this factor is rated high. In the next slide, we will cover the environmental factors.

7.10 Environmental Factors

Unlike technical factors, which deal with the technical and non-functional requirements of the application, the environmental factors deal with the environment where the software application is being developed. To determine Environmental Complexity Factor or ECF, Efactor needs to be determined. Efactor is derived by rating the eight environmental factors on a scale of zero to five and multiplying the rating with the weights assigned for each of the factors. The sum of these products is Efactor. The Environmental Complexity Factor is calculated with the formula, ECF = 1.4 + (-0.03 * Efactor). The eight environmental factors are shown in the slide. Note that the weights of these factors should not be changed. ‘Familiarity with the development process’ is a factor used to assess the familiarity of the development team with the process used to develop the application. For example, if waterfall development model is used to develop the application and the team is highly familiar with the model, this factor is rated high. ‘Application experience’ is a factor used to assess the experience of the development team on the application being developed or similar applications. If the application being developed is an eBiz application and the development team has experience in using the application, this factor is rated high. ‘Object-oriented experience’ is a factor used to assess the experience of the development team on object-oriented programming technologies like JAVA. As mentioned earlier, use cases are usually written for applications being developed by using object-oriented programming languages. In general, if the team is technically strong, this factor is rated high. ‘Lead Analyst capability’ is used to assess the capability of the business analyst who understands the business requirements and converts the requirements into functional requirements. If the analyst is able to elicit all explicit and implicit requirements from various stakeholders of the application being developed, this factor is rated high. ‘Motivation’ is used to assess the level of motivation of the development team. If the team is highly motivated and is happy to be in the project, this factor is rated high. ‘Stable Requirements’ is a factor used to assess the stability of the requirements. If there is a low chance of the requirements changing after the start of development, this parameter is rated high. ‘Part-time staff’ is a factor used to assess what proportion of the development team comprises contract or part-time staff. If the number of part-time team members in the team is high, this factor is rated high. ‘Difficult programming-language’ is used to assess the complexity of the programming language. If the language being used is relatively complex, this factor is rated high. Note that ‘Part-time staff’ and ‘difficult programming language’ factors have negative weights because these factors have a negative impact on the application development. Thus, high rating on these factors will increase the overall Environmental Complexity Factor. In the next slide, we will discuss how to calculate the Adjusted Use Case Point Count.

7.11 Adjusted Use Case Point Count

Once the Unadjusted Actor Weight (UAW) and the Unadjusted Use Case Weight (UUCW) are determined, the Unadjusted Use Case Point is determined by adding the two. The Adjusted Use Case Point is determined by multiplying the Unadjusted Use Case Point with the Technical Complexity Factor and Environmental Complexity Factor. The Adjusted Use Case Point describes the total Use Case Point of the application being developed, taking into consideration the technical and environmental factors. Though it was earlier mentioned that Use Case Point Technique is an algorithmic technique, it is a mix of algorithmic and analogy-based techniques, since the guidelines for determining the complexity of the actors and the use cases are defined based on data from similar projects. In the next slide, we will cover Simple-Medium-Complex technique.

7.12 Simple Medium Complex Technique

Simple-Medium-Complex or SMC is an analogy-based technique. Though it is not a formal technique like IFPUG, FPA, UCP, etc., yet this technique is widely used in maintenance, testing, and production support projects. Since it is relatively difficult to measure the functional size of requirements in such projects, a simple technique to measure the size is required. SMC technique is the solution to this problem as it offers a simple means to classify the work item and determine its size. In this technique, the overall application or the work request to be sized is broken into smaller components. For example, the application can be broken into modules or interfaces. In SMC technique, the objective is to estimate the effort required for the individual components. Before breaking the application into components, we should document clear criteria for classifying the components as Simple, Medium, and Complex. The criteria are defined to identify the complexity of the component or the application. It is not a mandate to have just three classifications. Based on the project’s nature, additional classifications like Very Simple, Very Complex, etc. can be included. However, it is important to have clearly documented criteria for each category. The criteria should be understood by all team members. It is also important that the criteria are not changed too frequently so as to allow comparison of the estimates over time. After this, the component or work request is classified based on the criteria. Now suppose that in an application, there are four modules of which two are simple, one medium and another complex. This is the size of the application as determined with SMC technique. To determine the estimated effort, a past baseline of productivity for each of the categories is used. Now let us consider that the productivity for one simple module is ten hours, that of a medium module is fifteen hours and that of a complex module is twenty hours. Thus, the estimated effort for the application would be 2 multiplied by 10 plus 1 multiplied by 15 plus 1 multiplied by 20. The total estimated effort is equal to 55 hours. As evident, SMC technique does not yield a single size measure for an application. It basically yields the number of simple, medium and complex modules within the application. However, some logic should be defined to yield a single number. The simplest logic is to assign a weightage for each category, then multiply the number of components within the category, and finally add all the resulting products. Now let us take the example shown in the slide. Consider that simple modules have a weight of one versus two for medium and five for complex. Based on the these weights, the size index for the example mentioned earlier can be derived as 2 simple multiplied by 1 plus 1 medium multiplied by 2 plus one complex multiplied by 5, which equals 9. Though SMC is a simple technique, yet it is not effective when you want to benchmark your size with the size of another application. It is ineffective because the criteria for classifying the components might be different among projects. That is, a simple component for project A might be a medium component for project B. In the next slide, we will discuss Planning Poker technique that is widely used in agile projects.

7.13 Planning Poker Technique In Agile Projects

Before we understand Planning Poker technique, let us discuss agile projects. Agile development is a buzz-word in software development lifecycle because of the level of flexibility, coordination, and accountability it brings in. In agile projects, requirements are documented in the form of a user story. User stories are short, simple descriptions of features told from the user’s perspective. They capture what users intend to do with the system. An example of a user story is “As a power user, I can specify files or folders to backup based on file size, date created, and date modified.” This requirement states that the admin or power user should be able to specify a set of files or folders to be backed up based on a few attributes. Due to shorter sprint cycles and dynamism in agile projects, detailed analysis of requirements and determination of size based on the function points or use case points is not feasible. Instead, size in agile projects is measured as story points. Like the way function point is the size measure in a normal development project, story point is the size measure in an agile project. Story points are used to determine the effort required to implement the user stories in a sprint. One of the most widely used techniques to determine the story points of the user stories in a sprint is ‘Planning Poker’. It is an expert-judgment method which means that the entire team is involved in determining the size for a given set of user stories. It is widely used because it is a simple, informal and fun way to determine the size. In addition to planning poker, other techniques are sometimes used. These include determining the size based on t-shirt sizes like S-for small, M-for medium, L-for Large, XL-for extra-large, etc. In some bizarre cases, the size is determined based on dog breeds like Chihuahua for small user stories to Great Dane for large user stories! In the next slide, we will focus on how Planning Poker technique works. Let us start with the first step that is reference user story, in the next slide.

7.14 Step 1 Reference User Story

The first step in Planning Poker technique is to identify an ideal or reference user story implemented in the past sprints, along with its story point. The entire team should agree that the chosen user story is the ideal one. The entire team should understand the requirements of the user story consistently. The reason why it is important to choose a good reference story is that the story point of other user stories will be identified relative to the reference story point. In continuation of the steps in Planning Poker technique, we will cover the next step that is ‘Explain user story’, in the following slide.

7.15 Step 2 Explain User Story

In the second step of Planning Poker technique, the story point should be explained to the entire team. The product owner or the business analyst should clearly explain the expectations of the user story. There should not be any ambiguity in understanding the requirements of the user story. In case of any clarifications, the team members should coordinate with the product owner, business analyst or subject matter expert. Only after all the team members have confirmed that the user story is completely understood, should the team proceed to the next step. In continuation of the steps in Planning Poker technique, we will discuss the next step that is ‘Planning poker cards’, in the following slide.

7.16 Step 3 Planning Poker Cards

Once the team has fully understood the reference user story and its story point, all the team members are given a pack of poker cards as shown in the figure. The poker cards are based on the Fibonacci series. These poker cards will be used by the team to determine the story point and reach a consensus. In continuation of the steps in Planning Poker technique, we will cover the next step that is ‘Determine the relative size’, in the following slide.

7.17 Step 4 Determine the Relative Size

Once the product owner answers all queries regarding the user story, the team members choose one of the planning poker cards which represents the relative size of the user story as compared to the reference story. None of the team members reveal their cards till all the team members have made a choice. Once all the team members have made their choices, they reveal the card so that the team can see each other’s cards. Relative size here refers to size of the user story based on size of the reference story. For example, if size of the reference story is 4 story points, the team has to determine size of the current user story based on this reference. If the user story is relatively larger than the reference story, it gets a higher size count than the reference story. In continuation of the steps in Planning Poker technique, we will focus on the next step that is ‘Discussion in case of contradictions’, in the following slide.

7.18 Step 5 Discussion in Case of Contradictions

Once all the team members reveal their choice of planning poker cards, it is common that most of the numbers may be close to each other. That is, most of the team members may choose cards in the same range with minor variation. However, there may be a few team members whose cards can vary highly from those chosen by rest of the team. For example, consider that out of 5 members in the team, 3 people have chosen ‘5’, one person has chosen ‘3’ and the remaining person has chosen ‘1’. In such cases, the entire team states the reason why each of them has made a particular choice. Once all the justifications are provided and healthy discussions are held within the team, the scrum master asks the team to make a choice again. So, steps four and five are repeated till there is not much variation in choices made by the team members. The resulting number is assigned as the story point for the user story. In continuation of the steps in Planning Poker technique, we will discuss the next step that is ‘Repeat the process’, in the following slide.

7.19 Step 6 Repeat the Process

The steps discussed in the earlier slides are repeated till all the user stories are covered. Then the estimated effort is determined based on the past productivity baseline. The total estimated effort is then compared with the available effort to check if it is feasible to complete the set of the user stories within the sprint deadline. For example, assume that there are 4 team members and the sprint duration is 10 days, with 8 hours of working time per day. Considering that there are no leaves planned by any of the team members, the available effort would be 4 multiplied by 8 and then by 10, which equals 320 hours. On the other hand, assume that there are 20 user stories prioritized for the sprint and after using Planning Poker technique, the estimated effort is identified as 400 hours. Clearly, there is a significant difference between the estimated effort and the available effort. In such a scenario, the scrum master will either negotiate with the product owner to de-prioritize a few user stories, or co-ordinate with the additional team members to ensure that all the user stories are delivered in the same sprint. In the next slide, we will summarize what we have learned in this module.

7.20 Summary

In this module, we covered Use Case Point technique, which is a hybrid of analogy-based and algorithmic techniques. Once all the use cases for the application have been finalized, each of the actors and use cases are analyzed. The size of the actors and the overall use cases is then determined. This helps in determining the size of the application. Based on the complexity and the weights associated with each complexity, the actor weights and use case weights are determined. These weights when added together results in the Unadjusted Use Case Point. Then the Technical Complexity Factor and Environmental Complexity Factor are rated. The Adjusted Use Case Point is determined by multiplying the Unadjusted Use Case Point with technical complexity and environmental complexity factors. Next, we covered Simple-Medium-Complex or SMC technique where the entire application is first broken into smaller components. Each component is then analyzed and classified as Simple, Medium and Complex based on predefined criteria. The past productivity baseline for each category is multiplied with the number of components in each category to determine the estimated effort. Finally, we covered Planning Poker technique used to determine the story points for user stories in agile projects. This involves explaining the user story to the entire team, followed by each team member suggesting the size using poker cards relative to a reference user story. In case of contradictions, discussions are held till a conclusion is reached. The past productivity baseline is multiplied with the total story points to determine the estimated effort. This estimated effort is then compared with the available effort to determine if all the user stories are feasible to be delivered within the sprint cycle. With this we have come to the end of this module. Following are a few questions to test your understanding of the concepts discussed in this module. Thank you and happy learning!

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy