Web Application Development with Microsoft Technologies

Sometime ago I went through a very useful book titled Software Estimation: Desmistifying the black art, and adapted some of the techniques listed in the book to create a standarized estimation procedure.

However, we deal with the fact that almost every month there is a new tool from Microsoft aimed to boost team productivity and reduce the effort required to build each piece of software, so it’s always a new challenge to give accurate estimations to our customers.

A critical thing is to record all the effort spent in every project and task, which can be used to calibrate the estimations and produce better results.

We try to follow the rule: “Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort.” as much as possible. 

Once we have a good requirements specification we produce a WBS (detailed task list) and we count web pages, sql tables or anything that can help to compute the effort required to complete the task, we compute and then we calibrate with similar tasks done in the past. We identify risks, review tasks checklist and then use a 3 point estimate to be as much accurate as possible. These can be just the first steps of any estimation procedure.

Once we decide which technologies to use (i.e. Dynamic Data, Entity Framework, ASP.NET MVC or any other tool which could help to improve productivity), we calibrate the estimated effort with the results obtained in similar projects using the same technologies, or the results obtained from some pilot using any other emerging technology.

Finally we allocate some contingency (in software development it’s quite needed!). In the past few projects we convinced our customers about having an agile methodology in place (such as SCRUM). One of the various advantages of SCRUM is that the customer will get periodic releases of the software, while paying for the time spent building the features on each iteration. Contingency makes then no sense, and it can help to reduce total cost which is a great way to convince customers.

When following an agile methodology the rule (count, compute and calibrate) is still valid, as the team needs to estimate each story at the begining of each iteration, and the same procedure can be followed on each iteration, also considering team velocity (productivity) and the actual results obtained from the use of the selected development tools.

So far we are very happy with the results obtained from this combination of agile methodologies and a structured estimation procedure, reducing risks and increasing our list of happy customers.