Scrum, Lean UX, & Extreme Programming Sprint Zero:

The length of sprint “zero” for a new product and the (debatable) necessity of common sprint zero expected outcomes may vary, but there is one task that must be completed, or the full benefit of your Scrum and XP practices will suffer:

Complete setup of the repository and automated build server – and send a build.

This is a critical step in establishing team transparency and Product Owner accountability – frequently delivered builds, even with mid-sprint potentially un-shippable product increments – are the exclusive insight of the PO into the progress of the product.  It is the Product Owner’s responsibility to determine the worthiness of the stories delivered and whether additional iteration is necessary; delaying this feedback loop robs the PO of crucial insights and undermines the team’s ability to gain fast and honest feedback.

The longer the team waits to send the first build, whether due to a still-emerging architecture or lack of finalized copy and assets, the more perfection becomes the enemy of the good (or in this case, the deliverable).  Scrum requires transparency and accountability:  remove dysfunctional Hawthorne Effect as early as possible by setting the precedent – from Sprint Zero – that the build is delivered to QA and the Product Owner early and often.