Jay I like they way tagging ideas have developed đ.
Re: Scoping
I understand concerns about a scoping tag. But I do like the idea of scoping because it shows users / potential users that the devs have though about a feature and have a top level âguesstimateâ of how much effort something is.
This is useful because (a) many a-time in a past life Iâve asked for features that seem trivial to me, but were in fact much harder and (b) the opposite - some features that appear hard, might actually turn out to be relatively straightforward. And for those that youâve not yet had time to think about you donât add a scope tag (or add one like âYetToScopeâ). We found that users were much more receptive to things not getting done if our devs had given some though and had a reason(s) why it was hard.
Also, Scope, has some bearing on Priority. A feature/bug scoped as âquickâ, and asked for by a fair number of people might get done. But if scoped as âhardâ then it might not get done.
âgroupingâ
One other thing that we used to try and do in my âmanaging a s/w company daysâ, was to âgroupâ certain features to address in a dev round. So, for eg., it might be that when done together, apparently un-connected features x, y, and z, allows you to more effectively address a wider market area - in this context maybe it means that WorkFlowy customers no longer have any reason not to use Legend (obvs, I just made that bit up to illustrate the point). But you canât do this without having a broader view on Legend and where it stands relative to competitors + the direction you want to push it in.
