Sprint. The reason this is done, is that the costs have now changed to implement this piece of functionality and needs to be re-evaluated by the onshore team.
Example 1: In one specific instance, the offshore team increased the hours estimate about 1/4 of the way thru the Sprint. When asked for an explanation they said, "they did not include any time in the estimates for proof-of-concepts, prototypes, demos or code reviews." Isn't AGILE all about proof-of-concepts, prototypes, demos? This just proves the offshore team really did not understand the Agile approach development.
The waterfall development process begins with each requirement broken down into functions. Each piece of functionality treated as a line item on the Sprint task lists. As the software is coded and becomes functional, it is walked through with the onshore team, business user/SME as well as the key stakeholder. This is where the offshore development team gets feedback thus clarifying capabilities that were "sort-of" delivered. The customer's comments are integrated back into the design or deferred, and are addressed later. If they comments and clarification are integrated back into the design, the rework is estimated, change orders issued and the cash register rings again.
Another hybrid technique replaces traditional reviews with functional demonstrations. As the work progresses, feedback from the onshore team, business user/SME as well as the key stakeholder is received the feedback is integrated or if it requires significant additional effort it is deferred and entered into the function backlog inventory and addressed in a later Sprint. If the feedback is required at that specific time it is, you guessed it, added to the Sprint task list, the work is estimated, change orders issued and the cash register rings yet again.
As each item on the Sprint task list goes through the waterfall development process, the output is demonstrated and signed-off on by the key stakeholder. At that point of the Sprint, the code based is integrated with other code produced during that Sprint. Once the time allotted for the Sprint development effort has elapsed, all completed items are assembled into one code base. At that point a formal Sprint review is conducted. A formal Sprint review signifies the end of a specific Sprint. The review is a step-by-step/functional piece-by-functional piece demonstration and walk-thru with the business users and key stakeholder. During the Sprint review the delivery is assessed against the sprint goals and objects determined during Sprint planning. Ideally the team has completed the selected functions for that Sprint, but it is not always the case. Since the Sprint review is the close of that iteration, official sign-off also takes place. Implementing this formal review and sign-off process reinforces the wrap-it-up habit and avoids the hanging Sprint problem.
Example 2: In another specific instance, the offshore team basically refused to begin development until they had a formal specification document and functional test cases signed- off on by the customer. In Agile, customer acceptance and approval to proceed is at every demonstration and functional walkthroughs. Again the offshore team reverting back to traditional methods and failing to grasp the Agile approach.
A hanging Sprint is defined as an iteration that is 90% or above done but never completed. The unfinished Sprints have been known to hang around for months. The development team just doesn't seem to have time to go back and complete the work in that they have moved on to the next Sprint.
A Fact of Life!
Many organizations have turned to outsourcing software development projects in an effort to reduce their costs. Despite its benefits,