Two main problematics are addressed in this article:
- How to estimate the size of the project software when the macro requirements are not completely defined?
- How to calculate the size homogeneously, when there are several products, agile projects and teams, and you need to have usable previous data to build the estimate?
The “Big Rock” technique is used to ascertain the size and estimate in the early stages of the project life cycle. The estimate is based on high level requirements, which will be refined as the project goes.
Introduction to the «Big Rock» approach
This approach enables to involve a team in a project estimation, besides its schedule and budget.
Teams can use the “Big Rock” method to generate an “order of magnitude” estimate and establish an initial budget. The content of major functions originates from estimation meetings conducted on several projects. That technique is also used to refine charge and cost estimates during the budget definition phase. The goal being to avoid estimating “mountains” or “small rocks”. That technique relies on the main functions of the product. The estimation of those main functions follows the same principles as agile method estimates.
- The estimate generated by a team results to be more reliable than an individual estimate.
- Estimates are never flawless. Some are high and others are low. They balance each others, since the law of averages provides a realistic estimate.
- Only select the size values available within the method. If a component is between two values, it must be rounded to the highest of both values.
- Establish an estimation schedule everyone agrees with, and a generic schedule as far as possible based on the results of former projects.
- Establish at least two different schedules:
- With x developers, the delivery date is y.
- With a delivery date y, x developers are needed.
- Describe the main functions according to the project scope, complexity and expected risks, not only taking into account the amount of day-effort.
The calculation of the size should not last more than one or two estimation sessions. The people involved in the estimation process are developers who will take part in the production of the final product. Other stakeholders may participate and should remain available to help define the scope and the content of the product all along the estimation process. Finally, other non technical stakeholders, such as project managers, for instance, may attend as observers.
The approach of main functions estimation is:
- Introduction – Workshop and schedule ground rules;
- Preliminary works;
- Reference size;
- Final review.
Preliminary works include the preparation of an architecture diagram and clear definitions of elements. If there is no architecture diagram, a team should work on it to ascertain the initial structure. That structure should not be frozen for the remaining of the project. The key here is to collect data with precision and to save it for future reference.
To avoid ending up with a structure that is not detailed enough, it is advised to keep three Main Functions description levels:
- First level: description for high and executive levels;
- Second level: description for main stakeholders and manager levels;
- Third and deeper levels: description for engineering and development team levels.
It is strongly advised to maintain the number of first level main function at least at ten, but to authorize a higher complexity for the second and third levels. Most of the time, the estimation of main Functions only requires two levels. Occasionally, building level 3 functions may be necessary for complex projects. Stories are at the next level, and should not be written before the entire set of main functions is estimated.
The goal of the estimation is to establish a consensus for the values used during the size estimate of main functions. That may be one of the toughest parts of the estimation process. Teams almost always tend to underestimate the number of points, or seem surprised when there are numerous points and to see the planning getting bigger. Many Waterfall project teams tremendously underestimate durations and deliver with delays. Actually, it is crucial to focus on complexity and risks, highlighting each function. It is then necessary to normalize the number of function points in respect with the reference base that was build based on former projects. In many cases, an activity of low complexity but time consuming, might end up being the same size as short but highly complex one.
But most teams prefer the T-shirt sizing method, most particularly to estimate main functions. Others define the size according to dog sizes (from the chihuahua to the St Bernard), or with different types of non numerical data. It is crucial not to assign points to the size while the T-shirt calibration is not complete. If function points are assigned too early, the team will only reason in points, and will not compare the size of main functions.
The smallest T-shirt size should be higher than the biggest story. Occasionally, many small related functions, not big enough to be the smallest T-shirt, may be collected in merging main functions. Generally, significant elements can be completed quickly.
The first step is to determine what is an Extra Small or a Medium function in terms of complexity, size and risks. It might be useful that the team accounts a few people who are experienced with Scrum and if the estimates can be based on the actual data of a Scrum team. Many teams like to have a higher granularity, it is then recommended to add other T-shirt sizes if needed.
The team must agree to choose which functions and sub-functions are of medium size. If no agreement is met, the team will have to choose another function, and execute that process until it can determine a medium size which can be used as a reference. Once the team finds a reference, intervals must be created in order to determine the following sizes: XS and XL. The remaining sizes may be defined during the estimation process.
For instance, integration of Internet interfaces is often used for medium size functions. Most of them reuse pre-existing software or tools to implement interfaces. The scope and functions are similar no matter the products, that is why it is a perfect choice for a reference function.
It is recommended to avoid defining the reference function in terms of hour-effort or day-man, since a developer A may work faster than a developer B.
This activity is an “order of magnitude” estimation type, it is not a detailed estimation. The main goal is to go through all the functions and to estimate reasonably, but not perfectly, the number of points of each of them, taking into account complexity and risks.
For the estimation, the main steps are the following:
- A function consideration: Can the size be estimated in less than five minutes? If yes, skip to question 3.
- If the size is too big, or the function is too complex, divide it in sub-functions. Some of them may already be detailed in sub-requirements, product requirements, functional requirements or other documentation.
- Discuss the function, in five minutes or less, until the estimators agree on the definition.
- Estimators indicate the size of the function. If some people influence others, you might have to use planning poker cards, votes or other methods. If necessary, the organizer may ask the following question: “Is it more or less complex than the average function?”
- High and low estimates are discussed. The uncertainty leads to a higher size.
- Estimators reach a consensus concerning the final size.
- The organizer records the result and the team goes on to the next function, and so on.
Once the team completed the sizing of all functions, the organizer reviews them and comes back on what is left to be discussed. The team is then asked if some issues or concerns remain on sizing. Answers must be shared among all attendees.
The organizer takes the T-shirt size table and converts it in points. The organizer must work with an expert in estimation experienced in Scrum. If possible, your medium reference function has to match the medium of a function the team knows. Medium points may be extrapolated from an “order of magnitude” estimation.
When attributing a value for function sizing, use sizes that are higher than the biggest story on which teams are planning to work on.
For instance, if the team agrees to say that the biggest story accounts 20 points, the smallest function must account 40 points.
The modified Fibonacci series may be used to define points for the remaining T-shirt sizes.
The following table is based on those instances:
Reminder: Each team has its own velocity. That velocity does not depend on hypotheses generated from orders of magnitude. Points attributed to functions may be refined later to match the actual velocity of the team. Different teams will have different velocities. The resizing of estimates is crucial for the monitoring and the management of the project.
Instances of size results
The following table shows the results of an application estimate with PC and web interfaces. Elements of the main portfolio are: communication, business processes, user interface and infrastructure. There are broken down in sets of more specific works, but still standard enough to be estimated. Those lists are prepared as part of works that are preliminary to the estimation. It helps organizing the estimation activities. For most projects, it would probably be a much longer list with at least an additional level of complexity.
|Communication||Ethernet Stack integration||XS|
|Communication||REST Library integration||S|
|Communication||Integration specific characteristics||L|
|Business processes||Database services||M|
|Business processes||Algorithm update||M|
|Business processes||Business Logic testing||S|
|User interface||PC development interface||S|
|User interface||Web interface||S|
|User interface||UI Testing||M|
|Infrastructure||Construction system configuration||S|
|Infrastructure||Life cycle supports||M|
Once the size is defined, it is possible to attribute points and a first quote may be produced after examination and discussion with the stakeholders. Thanks to the size mentioned above, that example enables to evaluate the size at 1,940 points. Considering that the team is able to produce 60 points per sprint, each sprint lasting 3 weeks, that project may be completed in 32 sprints or 96 weeks.
Teams and stakeholders discuss the scope, complexity and risks for key functions of the software product, being careful not to mistake them with schedule obligations. When the schedule is considered first, the work estimation tends to magically decrease to fit the schedule. At the end of the first estimation session, the results will probably be unacceptable for the main stakeholders. When it happens, the project definition should be broken down, redefined or refined to break down functions that are too big. A later estimation session will be done after the project scope update.
The Main functions sizing method balances the estimation between top-down and bottom-up methods that are used to estimate the size of the software. “Big Rock Sizing” also provides stakeholders with scope, project risks and complexity knowledge. “Big Rock” estimation may be adapted to answer the project organizational needs.