So at the beginning of the Agile project, you are going to have to provide some high-level estimates so you can get an idea of the size of your backlog items, you will have to plan for. For me, this is always a tuff and exciting portion of the project kickoff. Tuff that estimating something that is a “concept” and Exciting to get involved in creating a new application This is very important because it helps in the decision about priorities and what you should put on your plate first. Also, you will be able to get an idea of what features are likely to be worthwhile, and from the business side, it will give you an estimate of how big the team will be. You are saying about now “I don’t know much about all the items on the backlog” what are the features, tasks to build the features, and how do I implement them”?? The approach I have used before is to use a range of unit numbers from 1-20 indicating size. You can begin the estimation process just after you have completed your list of user stories. 1. Then Pick a very simple user story and give it a value of 1. 2. Assign the other user stories a corresponding unit value, representing how much more complex they are than the initial user story. Again 1-20 3. Complete the user story that you initially used as the guide and track how long (time) it has taken the development team to complete it. 4. Multiply that time by the complexity factor listed for the other user stories. Then add up all the estimates, and you have your first estimate. Remember to perform this exercise as a team. The information that can be gleaned from multiple team members working together is invaluable to the project, complications, different approaches, unseen issues, etc. Remember that Agile (scrum) is an adaptive process that moves from the analysis phase into the sprint execution phase.
Comments