Those who have already read through the pages of Agile Alliance and Scrum Alliance should have fair familiarity of the cycle of software engineering by now. The diagram is epic, and is widely used anywhere when there is a discussion on Agile Software development. It has been hard, but somehow I resisted myself to upload the same diagram here, but the diagram is still important for everybody to understand the core purpose of being agile.
Those who are already familiar to the diagram should be aware of the term “sprint” as well. For the others, the definition goes like this: Sprint is a time period within which the team completes the development of the backlogs committed by them at the beginning.
Those who are well aware of the software development life cycle should know that the life cycle does not contain the “development” alone. To give a software application a complete shape, development should be preceded by the analysis and design; and should be followed by various flavors of testing, bug fixing, and deployment. The proponents of Agile took a conscious attempt to fuse all these activities into a continuous set of activities, and hence they used the word “development” only to describe the activities within a sprint. However, the sprint activities does not remain confined within development only, it does have analysis, design, and testing.
Those who are well experienced with the commonly used software engineering models like waterfall or iterative should know that the duration of a phase is driven by several constraints like time to market, availability of resources, etc. Sprint, on the other hand, is fixed with duration. Its duration is 30 days. Agile practitioners around the world follow the same guidelines, albeit with some minor changes to fit their purpose. In most of the cases, the sprint starts on the first working day of the calendar month, and ends on the last working day of the same calendar months. Some take it to 30 working days, thus making a 6-week schedule corresponding to every start date. Although, people stretching the duration beyond 4/5 weeks are quite rare, and those who do so, have mastered the software engineering processes before getting into Agile. Most of the Agile development teams are charged up to show something been accomplished at the end of the sprint, and sooner the better. So it’s a self imposed restriction towards stretching or postponing the deadlines, everybody around an Agile development project know that something is getting done at the end of the sprint, which in turn is not far away on the calendar.
A software development project may have many sprints. Since the sprint duration is fixed, depending upon the size and complexity of the software application, the number of sprints varies. The sprints must be sequential, i.e., end of one sprint can only trigger the start of the next sprint. While the same team is expected to continue on the following sprints as well, the Agile methodology does not put any restriction on this area. In fact, at the end of each sprint, the product owner and the sprint master should take a joint review of the resource requirements on the following sprint(s) depending upon how much of the product backlogs should be converted into the sprint backlogs in a single sprint. End of sprint review would also help the sprint master to re-balance the team with the individual team members (e.g. somebody fell sick in the middle, or expected to go on a vacation on the following month, etc.).
No comments:
Post a Comment