The Community Blog for Business Analysts

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.

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:

Estimate Setting

a.      T-Sizing

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.

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

Pros

WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.

The hierarchy structure approach of WBS helps the project team to know the requirements of total project more accurately and specifically. This can provide the best accuracy estimate in case:

-      The requirements are well understood

-      Technology and methodology are not very new. It is based on past actual experience.

-      This project/application is similar to an earlier one.

As WBS is arranged in a hierarchy and constructed to allow for clear and logical groupings, either by activities (aka process-centered WBS), or deliverables (aka deliverable-oriented WBS), this results in a number of flow-on project management benefits:

-      The WBS is an essential tool to define the project scope. It clearly defines what is included, and what is not included in the project scope and deliverables.

-      The WBS lays the groundwork for accurate project costing. A detailed WBS helps carry out bottom-up project costing and estimating.

-      An accurate project schedule can be developed after a comprehensive WBS, which includes all tasks, is generated. Accurate scheduling increases the probability that project will be completed on time and meet client delivery dates.

-      A well-defined WBS reduces the risk of projects failing to meet goals and objectives. Because it identifies all tasks required to complete the project, the WBS reduces the potential for conflict on what is and is not included in the project, reduces the likelihood that key work will be omitted, and allows forward planning to ensure adequate resources will be on hand to complete project tasks.

-      The WBS can be used to manage outsourced service providers as well as internal project team members.

-      An effective WBS means project tasks can be delegated and managed. Because the work is properly defined, it can be scheduled, costed, implemented, monitored and controlled. This allows project managers to measure progress and ensures that the projects will be delivered on time, on budget and on scope.

Cons

There are many disadvantages to using WBS as a traditional estimation method.

-      During the bid process it does not always have enough time and information for the estimator to break the functional requirements down at detail (i.e., coding complete in hours). WBS is considered as more time-consuming than UCP.

-      Task breakdown is a technical view of the work in hand

-      Task breakdown is difficult to understand for the product owners. They don’t know what they are paying for and how much value is realized for finished tasks. i.e., the product owners do not realize the cost of each feature

-      Tasks breakdown gets into thousands of line items and difficult to maintain

-      Change in one task affects related tasks; change in requirement affects too many tasks

-      Difficult to allocate, manage task interdependencies, and assign ownership

-      Cannot measure productivity and improvements as the team members move along in a project

-      Cannot measure scope change; only able to tract effort change

-      Cannot link effort change to scope change where increase in effort is caused due to increase or change in scope.

-      Estimator needs to have understanding of software process applied into implementation of the project.

Relative Item Point

Pros

RIPs are an experience-based method that estimates the amount of software functionality based on requirement catalogue, or high-level descriptions of the functionality to be developed. RIPs are easy to calculate, can be taught quickly to multiple teams across the organization, and apply to any application-development project. RIPs can also provide a rough order of magnitude for planning purposes and can be used by teams to track their progress.

By estimating the size of a requirement item based on normalization of sampling, it is forced to use relative estimation that is better than absolute estimation.

The pros include:

-      Hours/Days promote much up-front planning. In order to get an accurate hour/day estimate, the estimator needs to task out the details of a feature. This is work that is better done as late as possible, since detailed implementation tasks are heavily dependent on the state of other related components and of the system as a whole.

-      It assesses similarities and differences, so it is less time-consuming than hours-based WBS method.

Cons

The cons include:

-      Past experience may not apply

-      Can misjudge similarities and differences

-      This method is highly dependant on the selection of requirement item samples. If the sample is not indicative enough, the estimate can produce inaccurate amount of days.

Appendix

Requirement Model

In which,

-      A use case defines a goal-oriented set of interactions between external actors and the system under consideration.

-      Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform.

Requirement Item

What is Requirement Item?

A requirement item (or a feature) is a chunk of functionality that delivers business value. Requirement items can include additions or changes to existing functionality. For planning purposes, some methodologies also use the notion of "work items" that can include new requirements, bug fixes, documents, and other artifacts. But items are the main unit of planning. Ideally, an item should adhere to the following criteria:

-      It should provide business value.

-      It should be estimable - it must have enough definition for the development team to provide an estimate of the work involved in implementing it.

-      It should be small enough to fit within an iteration - therefore, if it is too big, it should be broken down further.

-      It should be testable - it is understood that what automated or manual test a feature should pass in order to be acceptable to the customer.

The different methodologies use different terminology to refer to requirements. It is up to the team to decide which methodology or terminology to use.

-  Extreme Programming (XP) uses the terms User Stories or Stories to represent requirements.

-      Scrum uses Product Backlog to describe a feature list;

-      Feature-driven development uses Feature; and

-      Waterfall uses Requirement.

Similarly, there are various lightweight versions of the Unified Process (UP) that use Requirement and/or Use Case to define incrementally deliverable functionality. Ultimately, the goal is the same - to deliver business value regularly in small increments, and sooner rather than later.

When drawing up a requirement catalogue, items are initially described in a short paragraph, typically 2-4 sentences. This description represents a high-level summary of the item, a placeholder for preliminary understanding and a basis for future communication. It's rather like a headline for an article that will be written later. The goal is to spend just enough time describing the item to have a reasonable understanding of relative size, complexity, and priority compared to all other features.

Organizing Requirement Items

Managing a single long requirement list can be difficult. It is very helpful to organize items by specifying categories, higher level functional groupings (or use case grouping), business value or priority, and risk. Filtering and sorting by these various attributes can help break down a very large feature list into manageable chunks.