This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: Counting down to the iteration review
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
In a previous iteration we experienced a bit of a crunch leading up to the iteration review with our product owner, which resulted in a 1-hour slip to the iteration review. Not catastrophic admittedly, but this broke our rhythm and it's disappointing that we let it happen. How did this happen? On the penultimate day of the iteration we completed the user stories that we committed to deliver in the iteration planning game, so we agreed with the product owner to bring forward the next 2 user stories, each estimated at 1 ideal pair day. The team was so focused on getting the 2 additional user storiesdone that it basically lost track of time.
In the iteration's heartbeat retrospective the team asked if some structure could be put in place to help them have everything ready in time for the iteration review. Now our iteration review is conducted at 16:30 on a Tuesday and involves a demo of the iteration's user stories on the UAT box. And we use a cruisecontrol project to build and deploy to the UAT box. So I decided to implement a '3 cuts and you're out' strategy. I reconfigured the cruisecontrol project for UAT to perform 3 timed cuts (a cut is a full build and deployment). The first cut is taken at 15:00 and cruisecontrol fires a single 'beep'. The second cut is taken at 15:30 and cruisecontrol fires 2 'beeps'. The third and final cut is taken at 16:00 with cruisecontrol firing 3 'beeps'. Like a plane is guided in to land by runway lights, the audible beeps count the team down to the iteration review by deploying cuts of software from subversion. If user stories are not done by the third cut they are not included in the iteration review and they are not counted towards the team's velocity.
Previous Topic
