Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula - Part 2

Back in May 2010, I posted an article entitled Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula, which has been one of the most popular articles on this blog.

Amongst the feedback received there were many requests asking me to provide more details on how to devise the numbers to apply on the formula. This article expands on the topic by explaining my way of coming up with the numbers for the optimistic, pessimistic and realistic components of the Pert Weighted Average formula.

As explained here, the I use the following formula to estimate the duration to develop each user story that make up an iteration: (Optimistic + (4 * Realistic) + Pessimistic) / 6 .

How to apply the formula

Optimistic - I ask each developer to provide me with an estimation of how long it will take to complete each story they will work on. This is the number that I use for the optimistic component.

To estimate the other components of the formula I use a combination of grading user stories by size and complexity as outlined in the first article. However it is not as simple as that.

I don't see estimation as an exact science and therefore blindly applying a formula will not work under all circumstances. However, the formula does provide me with a consistent estimation procedure that has worked for at least 10 years now.

Another variable that I use in estimating the development effort is my team's velocity. I have a detailed record of the team's velocity recorded against functionality deployed to production. This helps me to compare actual duration of completed user stories against the effort that was originally estimated and use it as a basis to estimate the effort to develop stories that are similar in size and complexity ratings.

So here is how I devise the numbers for the rest of the formula.

Realistic - I search TFS (Team Foundation Server) for completed stories with similar size and complexity ratings and take the actual time that it took to develop it as the realistic component of the formula. 

Pessimistic - It is hard to estimate what a pessimistic duration would be because of many different variables that come into play such as risks associated with the particular piece of functionality, complexity, developer  experience and many other variables. I have met some development managers that double the duration estimated as the realistic and use it as the pessimistic. I don't blindly assign a number to it, I try to take everything into consideration in order to come up with an estimation that makes sense.

I don't think that there is a formula that you can blindly take to estimate software development effort. It is not as simple as that as there are many components that come into play in effort estimation, project management and software development.

What makes a good software developer?

Today at work I started to do some performance reviews. As I prepared the review papers  I started thinking about what makes me rate one developer higher than another.

So the question really is, what makes a good software developer? There are certainly many answers to this question and viewpoints will vary greatly. I don't think there is a definitive answer as the definition of "good" will change depending o what you are trying to achieve.

The following sections provide a high level summary of my thoughts on this very interesting topic.

Technical Skills

Technical skills are definitely very important, however I think that it is overrated. Attitude is far more important than technical skills. More on that later.

Possessing well developed technical skills enables developers to complete their tasks faster and therefore it has the potential to make them more efficient. In the past 2 or 3 years I have introduced new technologies in my current organization. Those projects didn't come without challenges, there were some rough days and times of low productivity. The developers with more advanced technical skills were able to understand those technologies and become more productive faster than the others. The real good developers became mentors to the other ones, without making them feel bad.

Attitude

Attitude is by far one of the most important skills a developer can have.

We all have different strengths and weaknesses, we can't all be technical geniuses or specialists in every single area of software development. When a developer faces a technical challenge and "hits the wall", no matter how good he/she is technically, attitude will determine the outcome. A good attitude and the ability to stick with it until the issue is resolved is key in this situation.

What I find particularly annoying is a developer that lacks these skills and as soon as there is an issue he/she immediately starts to ask the other developers without even researching the web or the team's wiki. Having said that, when facing technical challenges, there is a line when one needs to decide to stop researching and ask for help. I don't like to see developers stuck and not ask for help. Once research is done and a solution is not found, there is nothing wrong with putting your hand up and asking for help.

Business Knowledge

Business knowledge is also very important to enable a developer to work productively. Whether you work for an internal IT team or for a development house, having good domain knowledge enables developers to better participate in design meetings and to decide what delivers real value.

The time has past when developers sit in the corner and writes code according to the specs without asking questions or participating in solution architecture and other related tasks. We are all doing agile these days and moving to self-managed teams. Against what many people believe, implementing agile and self management is actually very hard. In order to have self managed teams you need developers that understand the business and are able to have meaningful discussions without project stakeholders. Without domain knowledge this is practically impossible.

Furthermore, well developed business knowledge enables developers to question the completeness and accuracy of user stories, either before or during development.

Lack of business logic is actually very dangerous because the developer does not actually know what it is that is being developed and what value it delivers to the business.

I would say that domain knowledge and attitude are some of the most important skills a good developer needs to have.

Openness for discussion

There are many different ways to address a particular technical issue or to develop a new function item. In my team we have daily stand up meetings and longer design/review meetings depending on what is going on.

Every so often we hold meetings to discuss the architecture and/or the best technical solution for a particular issue or functional item. During these meetings we discuss what the is the best solution and we move on to implement it without wasting too much time. I find very entertaining to see the developers argue to have their opinions or solution implemented. My own entertainment aside, these discussions are very important for the ultimate quality of our work because nobody knows everything, it is when we all sit around and workshop ideas that the best solutions are implemented.

I need to be careful and manage these meetings very well. Once we agree on a solution I quickly move on to the next topic or I end the meeting. The overall process works well, it has increased team cohesion and even the quietest developer starts to participate which is a bonus to everyone.

It is a win-win situation for me.

Appetite for new knowledge

IT is always changing. New technologies are often released to the market, new frameworks and methodologies are reviewed and update. It never stops. In order to keep up with it, developers need to be curious and have a appetite for new knowledge. You never really graduate from uni if you work in IT.

I could keep on going and identifying many other skills like knowing your tool set and many others, however I will stop here because I think that, in broad terms, I have touched on what really makes a good software developer.

I find really amazing that after a quick search on the web, most of the articles on this topic highlight technical knowledge, the need for good tools, knowledge on how to use those tools and other related technical skills. Although these skills are very important, they do not make great developers.

When I interview new developers I often ask if they know a particular technology or tool that is not listed in their resume. If they say that they know I probe a little further and may even ask why it is not on the resume, depending on the circumstances. The good ones, those who often get the job, say that whilst they don't have experience working with this specific technology, they can learn quickly and become productive in a reasonable period of time. If I can find evidenced of it in the resume and I confirm during reference checks, that will be the developer that gets the job.

In conclusion, I don't think that there is a definitive list for what makes good software developers as it varies depending on the circumstances. In broad terms, I find that attitude, openness to discussion and business knowledge are some of the skills that will give developers the edge they need to succeed in their careers.