On the Development of Feature-Based Sprint in AGILE

Abstract

AGILE methodology is widely used throughout the information technology industry for software development. In AGILE methodology, the delivery cycle is broken down into sprints or iterations. Many iteration-based AGILE teams use a time-boxed 1-hour discussion midway through a 2-week iteration (the team selects an iteration duration that provides them frequent enough feedback) (Cohn in AGILE Estimating and Planning, 2005 [1]). A sprint or iteration is expected to deliver a piece of functionality within a fixed period of time. The length of AGILE sprint is measured in number of days. Hence, it can be concluded that the unit of sprint is time, measured in numbers of days. But since AGILE is feature-driven, the unit of sprint should not be limited to time. There is a need to explore other measures that can be used to define or determine the length of the AGILE sprint. The purpose of this paper is to find out any other unit to define or derive the length of sprint. The paper also explores the various ways in which the AGILE developer(s), AGILE tester(s), and AGILE end user(s) can be benefited by changing the unit of sprint length from time to something else. This paper particularly talks about the possibility of using the “feature” as unit of sprint and lists down the advantages and disadvantages of using “feature” over “time” as unit of sprint. The term “sprint” or “iteration” is used as synonyms throughout the discussion.