It's a pretty common practice to add time to the end of your project plan in between the end of the last development iteration and production deployment. There are a number of activities that may have to happen prior to going to production, including:
- Final QA signoff of cards from the final dev iteration
- Any remaining defect fixes as a result of that testing
- Final user acceptance testing
- Preparation of the system for production
This period is often generically referred to as "stabilization". The issue I have is that this term implies that the system is not going to be stable at that point in the project, and this may even become a self-fulfilling prophecy.
The ideal in an agile project is that there are no defects at all at the end of each iteration. While this is not an impossible goal, in reality teams will usually strive to ensure there are no defects that would fit in the category of "critical", "high" or "medium", and more than likely a few "low" defects will escape the iteration. They will catch up on these in subsequent iterations, but following the logic you will still have some at the end of the last iteration.
So instead of referring to that final stage as "stabilization", I would probably prefer something like "wrapup" or maybe even "polishing".
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
I might call it "Release Prep", as it provides a good approximation of what occurs in the last sprint(s). The team is resolving any outstanding defects and is completing preparations for production deployment and release to the customer.
My views on project documentation specific to closure are listed at http://architecture-soa-bpm-eai.blogspot.com/2011/06/are-we-still-living-in-waterfall-era.html
Post a Comment