Hi Chris, I really agree with most of what you say.
Am 21.06.10 23:49, schrieb Chris Manning: > The only problem with this in our case is that we have tended to be lazy > by only adding stories and/or story points, for higher business value > requirements, as we are not likely to get to the lower ones anytime > soon, so it seems silly to plan them too much. We should probably add > them all though, as now I see that not having them is reducing our > ability to prioritise effectively. Well, I'd say to that that you really should not prioritize everything, but still start with the most valuable stuff. Your PO however should try to engage the team now and then to figure out very rough complexity estimates for what he wants and then use the value as well as the (first) complexity estimate for prioritization. Then you will break the stuff with the highest ROIF down further and improve the estimates by doing so. > So if the option could be extended to sort requirements by business > value and/or roif then it would give people to flexibility to use it in > slightly different ways depending on how they wish to do things. Yeah.. The problem with that is that having many options makes it really hard to evolve the product. :/ > As a developer myself (as no doubt most people using your product are > :-)), I am well aware however that you can never please everyone, and > that often what the users of a system think they want, isn't what they > actually want, and that often there are better ways. The tricky thing is > usually getting them to accept a change. As such I am open to other > options, and will even adapt to the current method if necessary. Well, the current best practice is to reduce the number of items in the backlog to a number that enables sorting by dragn'n'drop to not be hurtfull anymore. The logic being that if you have too many items you are generating waste and should instead focus it on being more detailed in the top priority items. Thats not the nicest of answers I gather - but the best practice we would like to encourage right now. Regards, Martin -- Follow Agilo on Twitter: http://twitter.com/agiloforscrum Please support us by reviewing and voting on: http://userstories.com/products/8-agilo-for-scrum http://ohloh.net/p/agilo-scrum http://freshmeat.net/projects/agiloforscrum You have received this message because you are subscribed to the "Agilo for Scrum" Google Group. This group is focused on supporting Agilo for Scrum users and is moderated by agile42 GmbH <http://www.agile42.com>. To post to this group, send email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/agilo
