Tuesday, September 15, 2009

Do you Spike?

Its been close to a year and half since my team started working on projects which were developed using Agile methodologies. Its been a great experience and a good one as well. In my current project we have hired some consultants from ThoughtWorks to help us improve our processes.

This is the first time we are implementing a project using Agile right from the scratch. We are planning to use various latest technologies for the development purposes. As part of up skilling process we are trying out some sample project. But in Agile terms it seems there is a term called Spike.

The official definition of Spike says, A very simple program to explore potential solutions to address a technical problem. The idea here is to put a pair of developers on the task and reduce the risk which will help in estimating the user story in a reliable way.

This is also the first time we are experimenting with the Agile estimation technique which involves the whole team while estimating for each user story. Traditionally estimation has been done at a very high level by experienced people which might include project manager, tech Lead and or a senior developer. I personally feel using agile estimation helps every member of the team to get a rough estimate of each user story. Every member gives his estimate and the scrum master takes into account an estimate which is acceptable to all in the team. If there is difference in opinion about the efforts required to complete a story, a healthy discussion is held as to why a certain team member feels it should take more or less time as compared to that of another person.

The way we estimated for a user story was based on the acceptance criteria. We were doing an estimation for a web based user interface system. We decided to estimate a story based on following

  • 1 - if the task can be completed within  a day
  • 2 - if the task can be completed in just over a day
  • 3 - if the task can be completed in 2-3 days time and
  • 5 - if the story is too big and needs to broken down into sub stories, or we might not have enough clarity and need more information about it.

The biggest advantage I see in this approach is that everyone's view is taken into consideration and it reduces the risk of one or other person influencing the estimated efforts. It also gives the team an overall idea of all the work involved in the developing a product. It makes the team more self reliant and reduces dependencies on individuals. It definitely helps in the collective ownership of the project.

No comments:

Post a Comment

How Travis CI saved my time?

Background Some time back I created an Ansible playbook to install software and setup my Mac Book Pro . I put the code for this on GitHub . ...