Learnings from first Product Review meeting

The first team starting Agile actually started their Sprint 1 this week with a day long prioritization meeting. Apparently this went a bit ... interestingly. A Tweeter in the meeting was sending out requests for help during it, and all indications were that around 4 PM things had become quite fractious and unpleasant.

According to a QA member at this meeting, there were three learnings. First, the meetings need to be a lot more structured, with time set to do X and time set to do Y. The user stories should have been prioritized, the estimates needed to be given faster without too much faffing, and the work items should have been broken into tasks (to enable estimation) before the meeting started.

Second, he said people needed to not get bogged down in conversations about trying to solve technical issues during the meeting. Sure, if a business owner has proposed X, and A will take 4 days and B will take 1, coming up with options A and B, presenting them to the owner and getting her instant approval for one or the other is vital. But these kinds of conversations need to be tightly monitored and focused, and the minute they get beyond the bare minimum you need for business feedback, you've probably gone to far.

(My experience, FYI, was that the first meeting took three to four times as long as it should have, so this kind of painful experience seems not atypical of a first time through.)

Finally, the scrum team would now like to not have the product owners there for the entire meeting. This is because one particular product owner kept pushing back on the estimates, saying they should all be smaller, and told them that the various things they needed to do as a part of the process were unnecessary. The team members considered this very disruptive and felt like it put too much pressure on them, that they couldn't give honest answers. I also heard that this led to the creation of an "us versus them" mentality - or perhaps reflected a pre-existing one.

The people who taught the SCRUM course we all took would probably see this as a "pigs versus chickens" thing, where the chickens (business owners) want to run things in the farmyard but it's the pigs who have "skin in the game." I found this a very negative simplification that ignored the fact that the chickens DO have skin in the game, as they will be the ones who get canned if their brilliant ideas don't bear fruit. What's unfortunate is that I see the Agile estimation process as a really vital way for the development team to communicate to the business owners the real costs of the choices they make in terms of effort; it gives people the opportunity to say, "Hey, why implement that as a text boxwhen we can do a drop down box for a third of the time and take care of a bunch of error scenarios while we're at it!"

Unfortunately now this team feels alienated from dealing with the business owners and wants to exclude them from estimation and task list creation, and I think this is a damned shame. Anyone out there have any ideas about how to handle this situation now that the damage has been done?