written by gunther gerlach-2009
There are many approaches for the estimation of a project. Some people will tell you to use the estimation based on story points from Fibonacci numbering system, however this approach only work when features are similar enough to keep a project velocity chart (average project velocity per sprint) in your project but, we all know that this is impossible, some features will need less than a hour of development and other sometimes two days. I am not saying that this methodology is not good, I am just saying that is perfect to get your project velocity chart from the project but if you really want an estimate to get the cost and scope from your project you need the estimate in a period of time, usually days of work.
Gunther Gerlach
written by gunther gerlach-2009
Use Cases: are in fact such a clear description of a feature, and the fact that each Use Cases could stand alone. They made it really easy to move cards representing the Use Cases around the
As a difference between this methodology from the others is that Agile Development teams capture requirements at a high level only, just-in-time for each feature to be developed. Agile scrum methodology requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product.
Gunther Gerlach
written by gunther gerlach-2009
Define your Sprint duration: A Sprint is a key when agile scrum process is implemented in SDLC. The Sprint defines the amount of time where a team will release a feature or list of features from a giving sprint backlog. This is an important decision. Scrum suggests 30 days, but they could a week if you estimate that will improve your team efficiency. The optimum Sprint duration depends on many factors. I suggest going back to your team and analyzing the perfect duration to be able of releasing a piece of software. I suggest 14 days, plus a planning day for your team and Stake Holders to create the product backlog prioritize requirements form different teams and, analyze the product burn chart. This will leave 2 weeks of intensive work and also, two Sprints a month.
Gunther Gerlach
