3 ms·
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
by 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.