3 ms·

Funny that you mentioned planning poker. I only recently heard about this strategy and it sounded like a great way to hash out the underlying difficulty of a fe

Funny that you mentioned planning poker. I only recently heard about this strategy and it sounded like a great way to hash out the underlying difficulty of a feature in a group atmosphere. There's also a free site for playing the game. It'd be nice if this somehow tied into my Pivotal Tracker account to actually set the points once agreed upon (and to also pull down the stories that don't have set points). http://www.planningpoker.com/ http://www.planningpoker.com/

jseban 15y ago
We do agile and planning poker in my team. The downsides is that all user stories must strictly be phrased from business/end user point of view, and there is no time to do any technical investigation before estimating. How it works is you sit in a meeting, and for the first time hear about a new feature, for example "user wants to click one button to see all historic events grouped by week". The questions that arise are usually along the lines of: * is this data available? we're not sure * is this particular part of the system messy and hard to change? we're not sure * are we really sure this is what the user wants? _all_ historic events? we're not sure And then, you estimate. Which means there is a lot of guessing and either/or going on.. and you churn through a whole bunch of stories in one sitting. Sometimes I wish for a more strict process with more of a technical proposal for changes. Either that, or to get involved with the business side right when they start discussing the new feature, to have a change to look into it/think about it from a technical point of view, while it's getting worked out to a user story.