tag:blogger.com,1999:blog-734195773111742577.post6052800806848213786..comments2008-08-22T07:11:41.015-07:00Jason Chambershttp://www.blogger.com/profile/10367857945070351431noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-734195773111742577.post-53601670095261886162008-08-22T07:11:00.000-07:002008-08-22T07:11:00.000-07:00Ade<BR/><BR/>We do things a little differently on our projects. We don't combine development and QA into the same sprint release. At the end of the sprint, we pass the release over to QA. So, if development are actively focussing on N, then QA are actively testing N-1 (whic leaves the architect to focus on N+1/2/3.Jason Chambershttp://www.blogger.com/profile/10367857945070351431noreply@blogger.comtag:blogger.com,1999:blog-734195773111742577.post-32925280663497964752008-08-18T08:40:00.000-07:002008-08-18T08:40:00.000-07:00"With agile you end up with a ton of releases accumulating - 1 for the end of each sprint. During the sprints, we pile features and fixes and we pray the documentation and QA can keep up with the pace."<BR/><BR/>This means that you're not "done done" with a feature at the end of a sprint. "QA sprints" suggest your back in the design/implement/test world and most people's interpretation of waterfall. You should try to alter the amount of development work in each sprint and possiblky the sprint length so that at the end of each sprint you have working, fully tested and documented features for users.<BR/><BR/>http://www.ademiller.com/tech/Ade Millerhttp://www.blogger.com/profile/16556557540358096447noreply@blogger.com