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