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 produce working, integrated, and tested code.
Iterations are characterized as follows:
- time-boxed - An iteration is a fixed agreed upon length (typically 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.
Process overview
The iterative process in use at Drew leverages 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.
Consulting process
The consulting process is a continuous cycle, with each step 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 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.
Development iterations
Each development iteration - typically between 1-6 weeks in length - works on a fixed scope of business requirements in a time-boxed period and delivers a working vertical slice of the system for customer feedback and evaluation.
- Decide integration scope - The team works through the prioritized project backlog creating estimates to determine which requirements will be implemented in this iteration. The scope of an iteration is not altered once the iteration begins.
- For each requirement - the following steps are repeated in a cycle until each requirement is implemented and functional:
- Development - Developers working alone or in a team (pair programming) implement each requirement in code.
- Integration - Developed code is integrated with the entire working system regularly (daily
) in order to identify bugs that only surface when interacting with the entire system. - Testing - The development team employs an automated test harness where possible as well as functional testing to asses the operation of each component and the entire system.
- Documentation - Documentation of the system occurs concurrently with development. System documentation is may be created by the developers - in a pair programming scenario, one developer can document while the other writes code. User documentation may be created shortly after each component is in a usable state and feeds back into the testing and development cycle.
- Review - At the conclusion of the iteration, the team asses the list of requirements and determines which should be considered completed. All requirements are assessed as either done or not done. Requirements that were not completed or even partially completed are returned to the backlog for the a future iteration. (This does not necessarily need to be the next iteration – the period between iterations is an opportunity to reassess the backlog.)
- Release/Customer feedback - A demonstration of the system is performed for the customer to solicit feedback and add or modify items on the backlog for future iterations. If this is a release iteration, the customer is provided with code that they can install and use in a test environment, or the customer is given access to a development installation of the current release of the system.
- Retrospective - The retrospective is an opportunity for the team to evaluate how well the development methodology and the members of the team worked together in the preceding iteration. The retrospective process should create suggestions for fine-tuning and otherwise adjusting the development process.