Brightmoon Consulting & Training

To avoid any confusion , surprises and more importantly ill feelings, it is important to define upfront (usually during sprint planning) what does a complete work means to ensure all scrum team members as well other stakeholder are aware and are on the same page. In another word, teams should come up with the definition of done. It does not have to be a perfect one. Definition of done can be continuously improved as the team and organization matures.

Below is the list that you can start with :-

i.   All acceptance criteria for a user story has been met (all items in a feature has been coded).
ii.  Code is commented, meets the agreed coding standard and checked into the source-control.
iii. Code has been reviewed or coded using pair-programming.
iv. Code is compiled or built without errors.
v.  Unit test case written and code has passed the entire unit testing by another developer.
vi. Integration & Regression test case written and code has been deployed & integrated into test environment testing by another developer and passed testing (or automated testing).
vii. User Acceptance Testing test cases written and code has passed UAT.
viii.Performance and load testing completed and passed acceptance criteria.
ix.  Deployment steps including configuration changes documented.
x.   All other related & required documentation completed.

This list can be continuously adjusted and improve to suit your own organization.

Agile methods recognizes and readily enables a project or development team to build in quality in their software product. It has introduced many methods to further improve the software development experience. Pair programming is one such method.

 It basically means 2 persons will work on the same piece of software at one time.  An extra set of eyes and brain will surely help. They will help to identify each others' blind spots. They can be instant discussion partners for difficult and complex code.

It may take a while for new comers to productively bring this into practice, may be a few iterations. But once the team becomes used to it, the productivity gain may exceed the cost of having 2 persons working on the same code.

Code reviews can be greatly reduced or totally eliminated. Testing effort may be reduced as well as it is expected the pair- programmers have built a good piece of module or software.
 
Other side effects of practicing pair programming are each other can learn one or things from his/her partner. And guess what ?? If one programmer became unavailable due to any reason (has to be assigned to a higher priority project or leaves the company), the other person can still continue with almost no effect to project schedule !!