Skip to main content

Agile Scrum Estimation


In this article I will try to explain the estimation process in Agile Scrum methodologies.

Before going into details here is just an advice: As the team has to estimate for every sprint it is a
good practice to follow same principles right from the first sprint and keep improving or modifying
the process as you progress through the project, but never completely ditch the process and start
afresh, unless every member of the team is completely at ease with the new process changing to a
brand new process will cause confusion above the team and all the lessons learned in all previous
sprints will be lost.

While using Scrum each item chosen to be developed in the sprint have to be estimated. Now
this estimation process is drastically different to the old practices like single person estimating for
the whole work and on behalf of the entire team or each developer estimating their own work in
isolation.

Estimation process in Scrum helps to bring the whole team work as a single unit rather than
individuals. So, what it suggests is to have a meeting exclusively for estimating all the work that is
planned for next commencing sprint. All team members should attend the meeting along with the
manager, testers, developers, business analysts and also the end user. Feel free to call up any other
stake holders if you deem are important for the development process.

Take up each requirement and analyse it in detail with in the team, unless the requirement is very
straight forward there should be some questions raised and subsequently answered by different
members of the team. Once the requirement is satisfactorily understood by all parts of the team
every member of the team except the end user and business analysts estimate the complexity of the
requirement. This complexity should be from a set of Fibonacci series – 1,2,3,5,8,13 etc.

Every estimating member should estimate the complexity in isolation, so poker style estimation is
a popular practice. But feel free to be creative. If the estimations of team are not same then the
reasons behind this variance is understood by asking the reasons behind each developers’ estimate.
This way the requirement is further discussed and everyone will have a better understanding of
the complexities involved in the requirement. Carry out the estimation process again and the
estimations should narrow down, repeat this until variance of estimations from all the members falls
within reasonable limits.

Carry out this process for all other requirements chosen for next sprint.

Based on the estimated complexity and the velocity of the team you can work out how many of the
planned requirements can be completed in the sprint. If all planned requirements doesn’t fit in the
sprint then chose the requirements in the order of their priority.

Some teams also allocate the requirements to individuals as part of this meeting, but this isn’t
mandatory.

Following this process will make sure that the entire team works in unison and every member of
the team will have exact idea of the work load. And more importantly the end user expectations are
pegged to what the team can achieve, not more and not less.

Finally, don’t blindly follow this process. Though the above explained process works most of the time
and is a major improvement to the prevailing practices there might be instances where it doesn’t
work or where there need some minor tweaks. So feel free to come up with your own process. Agile
is all about adapting to the circumstances. If anything in the entire agile process isn’t working for
your project then try to mend it. There is no hard and fast rule of what is correct and what is wrong
it all depends on circumstances.

Feel free to throw any questions you have at me, I shall try my best to answer them.

Comments

Post a Comment

Popular posts from this blog

Is caste system really bad?

Most of us, if not all of us, have said at some point that caste system should end for the good of society. I don’t actually disagree with that and until recently I am a strong supporter of that idea. But after some thinking during recent weeks I started to have second thoughts about it. Castes in the region I come from are mainly formed on the basis of their profession. Like priests are Brahmins, Gold smiths are Kamsali, Carpenters are Vadrangi and so on. This isn’t true for all castes but it can be fairly generalised. And in the days they are formed these professions are hereditary. So, this way of grouping similar profession people into a caste makes a lot of sense and in fact is very beneficial in providing unity and provides a platform to exchange new ideas and improve the professions. If the caste system remained to just grouping people from similar professionals it would have never gone into the troubled waters as it is now. Caste system has become unpopular because of so...
Post a Comment
Read more

Various ways to react to a mistake

When a person makes a mistake it is fascinating to see how they respond. Based on the situation and nature of the person who makes the mistake there are various ways one can react. I tried to broadly divide the reactions into following 7 categories: No I didn't make a mistake – I never do any!  This is the kind of response we give when we don’t want to agrees to the mistakes we do. Even the mistakes of worst nature i.e. blunders would not deter us from self-protection. This behaviour could be because the person really believes that it isn't their mistake or it could be that the person knows it but isn't brave enough to accept the mistake.  The problem with this behaviour is that the person doesn't learn from the mistakes and keep making them again and again.   It’s not my mistake, I did it because... Most of us use this in scenarios where we try to find excuses for our short comings. The hard core section of this group of people...
Post a Comment
Read more

Development Process

I worked in different roles for different companies and in each role there was some talk about reviewing and optimizing development process as it was thought that the current process is either too laborious or too simplistic, yes too simplistic processes aren’t too good either. You might think that simple process is the way to go but not always. Let me explain. If the team is working on a green field project, the development team is aware of the business domain, are technically capable of producing good code and detailed coding standards are defined at team or company level then simple process of [design-> develop->test->deploy] will work. But if this team has been working on this project for some time say 6 months and a new developer joins the team then this simple process will start to fail. By the time this developer joins the team there is already some code in place that is developed to certain standard and this developer doesn’t have any knowledge of the application tha...
Post a Comment
Read more