We had an interesting discussion within our team today about estimation and thought I'd share some of the things that came up. To fill you in we currently use relative estimation to size our upcoming stories. In it's most basic form this consists of taking a story that is well understood by the whole of the team and then using that as a basis to size an upcoming story. We then decide whether the upcoming story is either smaller, the same size or larger. In fact we use a slightly more involved version of this where the known stories are assigned story sizes: 1, 2, 3, 5 and 8 but the basic idea is still there.
Our particular team is the most diverse in terms of skillsets in the whole development department. Within the team we work on everything from front end web development in C# through to back end systems written in C++. This wide variety of skillsets was in fact the cause of discussion, the question being how do you do effective relative estimation if you work in an agile manner and therefore anyone could pick up the work. Obviously a story that is related to the web front end which is picked up by one of the team members who is unfamiliar with the language or area will take them longer than somone who is and vice versa. So do you estimate solely based on the effort involved in completing the story, for example based on things like the of amount of code to write or do you also include the effort of familiarising a team member in that area. If you choose to include both do you then assume a particular knowledge set when you estimate? Do you assume that you are estimating based on one of the members of the team familiar with that area, as one of the members from the other end of the spectrum or take an average? What happens though when someone unfamiliar with an area picks up a story that was estimated with someone who was familiar in mind? Your estimate is surely going to be innacurate as what it was based on is now invalid. Do you then go down the path of instead of giving single point estimates giving a range from low to high? Here the low estimate would be someone familiar with the area and the high estimate would be someone that is unfamiliar in that area.
The other way to look at it is that you just include the effort to complete the story. To anyone outside the team estimates might still appear to be out depending on who picks up the story. Within the team you can evaluate whether the actual effort spent on the story not including familiaristation was the same as the estimate. If people are working on areas that they are unfamiliar with then rather than the estimates themselves being out the velocity of the team will drop. We certainly don't have the answers yet but for the moment this is the way we've chosen to go as we don't want to go down the route of ring fencing particular individuals to work on certain areas as these people then become potential bottle necks. As with everything we do we'll see how it works and adapt it until we have something that does.