The Community Blog for Business Analysts

Thai Son
Thai Son

Relative Item Point (RIP) Estimate Methodology

ABSTRACT

Software development is burdened with high levels of complexity (and many unknowns), yet it requires perfection for the software to compile and work. Because of these factors, no estimation approach is going to be foolproof. It is believed that relative item point estimation is just as accurate as any alternative (WBS, UCP) while offering the advantage of being far more simple and elegant in comparison. 

 

Relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing. That is, instead of trying to break down a requirement into constituent tasks (and estimating these tasks) as what are often being done with Work Breakdown Structure, the estimator (e.g., TA, BA) compares the relative effort of completing a new requirement to the relative effort of a previously estimated requirement.

 

The estimator can use any estimation method that he/she prefers, as long as it is not excessively detailed and does not require too much time. The idea is to rapidly produce a rough estimate that is good enough for strategic planning, but one that should not give the illusion of being definitive.

Term

Description

BA

Business Analyst

Item Point

A subjective measure of the size (or bulk) and complexity of the requirement item. The estimator assigns item points by considering several factors and estimating how big an item is compared to other items in the catalogue.

IP

Improvement Proposal

Requirement Catalogue

(or Requirement List)

Catalogue is a list of requirement items that can be grouped by business use cases. The catalogue is produced from eliciting/analyzing the high-level user specifications.

Requirement Item

A requirement item is described as a function in a business use case. This function can be a specific purpose to indicate WHAT user wants (not WHAT the system is supposed to accomplish). See further on Requirement Item in the Appendix section.

RIP

Relative Item Point

TA

Technical Architect, Senior Engineer

UCP

Use Case Point method is a software sizing and estimation based on Use Case document.

Use Case Transaction

Transaction is a "round trip" from the user to the system back to the user; a transaction is finished when the system awaits a new input stimulus. It's an atomic set of activities that are either performed entirely or not at all.

WBS

Work Breakdown Structure is a (deliverable-oriented) hierarchical decomposition of the work to be executed by the project team to accomplish projects objectives and create the required deliverables.


OVERVIEW

During requirement analysis the team may have a requirement item that requires the design of a complex optimization algorithm as it may not require many lines of code but instead a lot of thinking and analysis time. Also, it may have another requirement item that is user-interface focused, requiring significant HTML tweaking across multiple browser types and versions. Although this work is not complex, it is very repetitious, requiring a lot of trial and error. Another requirement item may require interfacing with a third party product that the estimator has not dealt with before. This is the requirement with risk and may require significant time to overcome teething issues.

 

The effort is determined based on three factors: complexity, repetition, and risk.

 

 

RIP represents the amount of effort required to implement a requirement item. This is the calculation of not only complexity but also risk inherent in and the repetition involved in implementation the item. Its focus is to estimate the requirement catalogue based on relative magnitude (size) and complexity / difficulty.

 

Note: It doesn't require detailed specifications to make effort estimates. If the customer wants a login screen, it doesn't need to know what the exact mechanics, workflow, screen layouts, and so on, are going to be. Those can come later when the team actually implements the requirement during development phase (or during the sprint). All we need to know at this early stage is roughly how much effort the login function is going to require relative to, for example, a search requirement that we had already estimated. It could be said that if the search function was indicated as 'Medium' (i.e., allocated 5 points), then the login function should be indicated as 'Small' (that is 2 points).

 

RIP estimation is done using relative sizing by comparing one item with a sample set of already sized sampling items. Relative sizing across items tends to be much more accurate over a larger sample, than trying to estimate each individual item for the effort involved.

 

The benefit with using RIP is that it is not time-based so does not require deeply detailed functional breakdown like WBS, if something is big and complex in most cases it will stay big and complex. And, it is not transaction-based like UCP because it takes into account the complexity of internal processing inside a requirement item. It is more efficient to estimate using RIP in several specific context of work than using WBS and UCP.

 

ENTRY CRITERIA

Requirement Catalogue

The catalogue is in forming of a list of requirement items, for example:

 

#

Requirement Item

Use Case

1.1

View innovation details, including the innovation list and the detail when user selects

UC01 - Innovation Management

1.2

Search innovation (supports restricted and full facilities)

UC01 - Innovation Management

1.3

Add/Edit innovation details

UC01 - Innovation Management

1.4

Evaluate innovation progress (Progress tab)

UC01 - Innovation Management

2.1

View list of registered users

UC02 - User Management

2.2

Add new user (note: user account is loaded from Active Directory using auto-lookup functionality)

UC02 - User Management

Estimate Setting

a.      T-Sizing

Complexity

Acronym

Item Point

Very Small

SS

1

Small

S

2

Small Medium

SM

3

Medium

M

5

Medium Complex

MC

8

Complex

C

13

Super Complex

SC

21

Epic

Epic

34

Some key points as below:

-      Using only complexity labels above for estimation

-      Using a number series from the Fibonacci sequence (each number is the sum of the two preceding numbers) to express the difficulty of a manageable task. 34 is the most complex and largest value.

-      Anything smaller than a 'Very Small' is free.

-      Anything bigger than an 'Epic' is X-Epic. An X-Epic item must be broken down.

b.      Effort Distribution by Process

This can be re-used from WBS approach.



#

Software Process

Distribution

In Scope

1

Requirement

10%

Y

2

Design

11%

Y

3

Code & Unit Test

38%

Y

4

Test

23%

Y

5

Deployment

2%

Y

6

Customer Support

2%

Y

7

Project Management

10%

Y

8

Configuration Management

2%

Y

9

Quality Assurance

2%

Y

 

Total

100%

 

Sample for Estimating

There are two common ways to get started estimating the requirement items.

-        The first approach is to select an item that is expected to be one of the smallest items will be worked with and said that item is estimated at one item point.

-        The second approach is instead to select an item that seems somewhat medium and give it a number somewhere in the middle of the range expected to use. This means look for a medium-size item and call it five story points. Once we have fairly arbitrarily assigned an item-point value to the first item, each additional item is estimated by comparing it with the first item or with any others that have been estimated.

 

IMPORTANT NOTE:

-        The sampling items need to be indicative of all the items. Estimator can do task-breakdown estimation of these items and extrapolate it to the whole lot. The picked-up items need to be good enough that they are exhaustive of the scope of project.

-        Item points are used to estimate items on the requirement catalogue, i.e. items that represent value to the customer. They are not used to estimate effort to produce artifacts (e.g., in WBS) needed by the development team. So use item points to estimate the requirement items, not tasks.

 

For example, a list of sample requirement items as below.


 

Some key points as below:

-      The most important thing to remember is that item points do NOT equal units of time. The estimator can try to convert item points to days, or estimate in days or hours, and then try to convert that to item points. In this IP document, the Coding Unit is prefered to use in unit of days.

-      The coding unit is identified by TA.

-      With a new project it is impossible to know how quickly features will be produced. There are just too many variables, e.g., learning of the domain & tool set, agreement within the team, stabilizing of work patterns. More risk may be added into and got it more complicated.

 

Estimation Process


 

Step 1. Requirement analysis

From the high level customer's requirements, the estimator, uses his/her expertise analysis skills, to produce the requirement catalogue that can be in form of use case names with a list of functions, or can be a list of features required to do in the system.

 

Step 2. This is the first step of sampling process. The estimator picks up a number of requirement items from the catalogue, those items will be considered as requirement sample. The selection of items must be representative of the population, and must be exhaustive of the project scope.

 

Step 3. Based on technology & framework assumptions, the technical expert will estimate coding effort for each requirement item in the sample. This works similar to WBS method.

 

Note: The estimation should include the amount of effort required to get the requirement done. The 'done' here should ideally involve coding effort only, neither testing nor other effort to fully complete the item. The effort distribution is based on estimation setting. Total effort is the sum of all distributed ones.

 

Step 4. Average productivity is calculated as an average number of the coding effort per item point for all sampling items. This is manday(s) to finish an item point. The estimator then applies T-Sizing values into these items.

 

Step 5. With RIP Template given, the estimator walks through the catalogue and identifies the size of all requirement items by selecting the T-Sizing value for each item. Item point, coding effort, and total effort will be calculated automatically.

 

Step 6. The total effort amount calculated from above step is considered as modelled effort. The estimator may add further effort, buffer (e.g., for risks), and management contingency into that. This works similar to WBS/UCP methods.

 Exit Criteria

Use case list of number of requirement items with the complexity identified and size calculated. This will come up with total coding effort and total development effort (as modeled effort) BEFORE adding risks, contingency management, and others.

COMPARING ESTIMATION METHODS

Use Case Point

Use-case points, as the name implies, are derived from the information captured in use cases. UCP calculations represent a count of the number of transactions performed by an application and the number of actors that interact with the application in question. These raw counts are then adjusted for the technical complexity of the application and the percentage of the code being modified.

Pros

UCP is applicable to waterfall development and can be used by teams following Agile methodologies as long as the Agile teams use UCs to gather requirements.

-      UCP can be calculated early in a project's life cycle and then refined as more requirements are specified and more of the design work is completed. As a result, it is useful for project planning, team performance management, and retrospective performance evaluation.

-      Not necessary to involve the experts

-      Technical expertize not needed

-      Can be used for rough pre-sale estimation

-      Can be made very fast (e.g., ball park estimate)

-      Intuitive enough for the customer

Cons

-      This method counts the number of transactions, and then calculates the complexity. While there are kinds of 'engine' requirements that need complex algorithms, that makes the estimate is not accurate.

-      Actor identification needs technical details in case it involves many protocols the actor will use.

-      Estimates only requirements, but not tasks that have to be estimated later.

-      Strongly depends on the requirements completeness

-      Coefficients (e.g., environmental and technical factors) need to be adjusted for the company.

Work Breakdown Structure