In the software outsourcing industry, our usual projects involve upgrading and maintaining existing legacy systems for our clients so that they can focus on new opportunities.
In my early days as a typical Project Manager, I ask for available documentation and work products from the client and begin estimating. Equipped with piles and piles of historical information from previous projects, I size up the scope in terms of LOC, number of pages, or whatever size drivers that represent the deliverables. Then applying the PM Tool called “Expert Judgment” I will choose the relevant estimation rates to get the effort of each deliverable, add some risk factors, and sum them up to get the total cost. Plot this in a Gantt chart and an estimate is produced.
The problem with my previous approach is that documentation is often not available or outdated (or sometimes they are written in foreign language). Each project has unique variables that may not be captured by historical-based estimation. At the end of the project, when the ACTUALS were compared to estimates, the differences were Outliers! There were several adjustments along the way as the team learns more about the project. Contractual adjustments are usually very cumbersome and costly.
Now instead of estimating in silo, I involve my team in exploration and estimation. In agile, estimation is done best by the people who will actually do the work. Below are the steps that we usually follow in coming up with a more confident and relevant estimates:
1. Explore the system to be maintained, build and run it
When NDAs are signed and the parties are free to share information, we ask our clients for an environment where we can execute and explore the software. In cases where environment setup is expensive or is difficult to setup in our site, we arrange for customer visits. We also ask for test accounts for cases when the software is accessible via Internet.
2. Ask for an equivalent product backlog (list of maintenance items)
Deployed software will have change requests, bug list, task list and technical debts. To gain further understanding of the in scope items, we run-through the list with the customer. Here is a simple backlog list. You can download the template at the end of the article.
3. Relatively size-up the product backlog items (using T-Shirt Sizing or complexity scales)
Using the scales in our planning poker cards, we relatively size each product backlog item
-T-Shirt Sizing: XXS(<1point), XS(1pt), S(3pts), M(5pts), L(8pts), XL(13pts), XXL(21pts) or
– Complexity Sizing: NEGLIGIBLE(<1), VERY EASY(1), EASY(3), MEDIUM(5), DIFFICULT(8), VERY DIFFICULT(13), VERY VERY DIFFICULT(21)
4. Spike for an initial velocity
Our team will perform a spike to implement 1 medium-sized (5 points) product backlog item to determine the effort needed. As much as possible, we try complete the product backlog item from end to end (pass an initial definition of done). In case time is limited, we estimate the effort needed to complete the remaining tasks to complete the backlog item. The more spikes we perform, the more accurate our estimation becomes. This will depend on how much effort your company can spent for pre-contract activities. On the example below, 1 medium(5) and 1 small(3) items were implemented in Spikes completed with 23 hours of effort. The computed assumed velocity is 2.88 hrs per point.
5. Estimate the product backlog
From the empirical data gathered from the spike(s), we revisit the product backlog and re-size the items (change from M to S or from XL to XXL etc.). Using the initial velocity, we can determine the approximate effort per backlog item.
To simplify estimation, I recommend fixed team size across the duration of the project depending on the computed effort and the total duration constraints (if any). For example, assuming a capacity of 150 hours per person per month, to determine the team size of a 1150-hour-3-month project = 1150hrs/3mos/150hrs = 2.55 Fulltime equivalent engineers (RAW team size).
6. Add capacity for Technical Investments and Technical Debts
For a complete estimate, you need to consider the efforts spent on technical investments, technical debts, and other unaccounted tasks/risks. As my own rule of thumb I add 50% from total Feature points for Technical Investment and 10% for Technical Debts. You may have your own factors. To know more about technical debts and investment, read my blog entry on Technical Investment over Technical Debt.
In the example, I use 2-week sprint. It is my recommended sprint length as I discussed in Everything About Sprint Length.
You can use the figures to fill-up your own organization’s estimation template.
From experience, this type of estimation will take 1 to 2 weeks. Aside from having a more realistic estimate, we have a chance to immediately work with the customer from day 1 and show them our capability from the results of the spikes. Hopefully will gain their favor in choosing your service as their developer of choice.
Here is the template I used for the samples above: Simple Product Backlog Template
– Agile Pinoy