Iterations or "sprints" are the fundamental building blocks of an agile development process. Iterations are short - no more than a few weeks in length - and deliver a complete vertical slice of the software system to enable customer feedback and acceptance testing. To do this, each iteration incorporates a complete life cycle of design, coding, integration, and testing. An iteration must produces produce working, integrated, and tested code.
...
- time-boxed - An iteration is a fixed agreed upon length (typically between 1-6 weeks) and is "time-boxed" in that it has a fixed start and end date. This is an important contrast to incremental development, where the system is built in small pieces, but the work is not synchronized to a time box. Time-boxing is an effective technique for managing scope, facilitating consistent results to the customer and customer expectations, providing for more accurate planning, and creating a team rhythm.
- fixed-scope - Tasks for a particular iteration are assigned from the project backlog. Once assigned, the scope of an in-progress iteration is not altered.
- completed or not completed - Each of the backlog tasks are considered either completed or not completed at the conclusion of an iteration. Uncompleted and partially completed tasks are not automatically rolled forward to the next iteration, but return to the project backlog for reprioritization.
...
The iterative process in use at Drew leverages too two concurrent and interrelated processes: the development iterations themselves, and the consulting process that is responsible for gathering user stories and use cases from the customer. In the case where it is possible to have full participation of the customer on the development team, the consulting process can be fully integrated into the iterations themselves, however in most practical applications at Drew this will be a parallel process that feeds requirements into the project backlog and gathers feedback from an external customer.
...
The consulting process is a continuous cycle, with each step providng providing the opportunity to feed back to the previous in order to refine the requirements being generated for the development team.
- Initial customer contact - Typically informal, the initial customer contact may be an email, phone call, or walk-in visit where the customer expresses the business problem they are trying to solve. The individual responsible for the initial contact must triage the request and determine if it requires more extensive investigation or can be solved immediately as a minor task. The result of the initial customer contact should be an issue tracker incident that describes the engagement and allows for comment from the customer and the rest of the development team. The customer will be furnished with a link to documentation on our consulting methodology and a new wiki page where they can begin to draft user stories for our next customer meeting.
- Customer meeting - This is a guided interview process in which user stories are elicited from the customer. The customer has had time to think about the user stories and the interview team has had the opportunity to generate specific questions for the customer prior to this meeting.
- Translation of the customer user stories into use cases - The development team translates the customer users customers stories into use cases and documents them in the wiki.
- Customer verification of use cases - The customer provides feedback on the accuracy and priority of the use cases that have been generated by the development team. If necessary, the process loops back to user story and use case generation based upon customer feedback.
- Generate prioritized backlog tasks - The development team translates the use cases into bite-sized development tasks for the prioritized project backlog. Backlog items should be scoped so that they can be accomplished completely within an iteration. The backlog items are created as tickets in the issue tracker to be worked by the development team.
...