My Opinion

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

These days ‘Agile’ has become so prevalent that every developer must have come across this word. The word in the market is that Agile is the best way forward, though this isn’t true for every project developed but true for many of them. In this article I want to introduce you to Agile, if you just heard the word ‘Agile’ and want to know a bit more then you came to the right place. Agile is actually a simple development methodology, there are various types of Agile methodologies but all of them are closely related to each other and have same overall principles. In this article I shall details the overall principles that all the agile methodologies follow. It may be the case that I speak mainly about ‘Scrum’ methodology as I worked mostly in projects that used Scrum. Before agile has been introduced all the software development projects has more or less the following lifecycle: Requirement gathering -> Analysis -> Design -> Develop -> Test -> UAT Deploy -> UAT ->

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