With a software project like this, I think it's important for all available bugs and change requests to be raised, no matter how small. Capturing as many as possible, even 'nice-to-haves', actually improves the prioritization process by giving a more realistic backlog. There will always be certain 'quick wins' that can be thrown in without detriment to larger changes and add real value to a given update. It might be a nice idea to have a 'virtual' backlog for user prioritization, to be used as a feedback tool but, relistically, there will be a number of determining factors that the user base just won't be privy to.
That said, I really don't intend to slam your comment, just thinking out loud. :)
With a software project like this, I think it's important for all available bugs and change requests to be raised, no matter how small. Capturing as many as possible, even 'nice-to-haves', actually improves the prioritization process by giving a more realistic backlog. There will always be certain 'quick wins' that can be thrown in without detriment to larger changes and add real value to a given update. It might be a nice idea to have a 'virtual' backlog for user prioritization, to be used as a feedback tool but, relistically, there will be a number of determining factors that the user base just won't be privy to.
That said, I really don't intend to slam your comment, just thinking out loud. :)
Ninja edit: typo. Hope no one noticed! ;)
Well put.
I think we agree. Its a good feature, I just want to see how it stacks in a backlog.
Then let's agree to agree! ;)