+36
Planlagt
Drag and drop ranking of backlog independent of themes (e.g. T1S1, T2S2, etc)
I'd like to be able to rank stories on my backlog independent of themes so that I can implement features and themes incrementally.
For example I'd like to be able to order theme 1, story 1 then theme 2, story 1 as my priority
Svar
Under vurdering
Hi Sandy
Thanks for the feedback. This is an issue we're actively trying to address, but I'm not sure we've quite figured out the perfect way of fixing it yet, and hence not implemented it. Hopefully you can help by answering a few questions:
- When do you actually need to order these stories? The reason I ask is that grouping stories by themes seems to be a popular feature for most users, however I understand some stories in some themes may be higher priority than another theme higher in the backlog. When would you actually envisage ordering the stories and viewing the stories in order of importance?
- If we added a priority field to each story so you can enter a number say between 0 and 100, would that suffice? In the sprint view, one could then order by backlog order or priority order.
- Do you think it's necessary to have two views for the backlog, one by theme, and one which is simply a long list that you can re-order?
Thanks,
Matt
Matt
I like this suggestion and understand why there's a need for it. Drag and drop ranking would be really slick, even if it's only ranking features within themes.
That aside, grouping and ranking stories by themes is great if you are allowed to complete an entire theme before moving on to the next highest ranking theme. Not all teams have this luxury; however, especially service-based teams.
Having the ability to rank at a feature level vs. themes level gives a PM the ability to see the highest customer affecting features across all themes. These can be easily identified and moved into Kanban without being impeded by features that have lower customer impact.
Ultimately, I would rather see this type of ranking incorporate severity and priority; severity being customer impact (1=high, 2=med, 3=low), and priority (1=need, 2=want, 3=bonus). It would be great to see the overall list sorted by severity.priority (1.1, 1.2, 1.3, 2.1, 2.2, etc) as an OPTIONAL view and OPTIONAL export type.
Hi Treblin
I'm not sure if you are aware, but you can drag and drop stories (features) within a theme now. Also, if you want to move a story to another theme, you can click on the cross (drag icon) and a dialog will appear allowing you to move the story to another theme. Are you aware of this?
I really like your solution of severity and priority being combined into a simple digit.digit format, with only 3 options. One of my concerns has been that should we allow any number to be used for prioritisation (such as 1-100) the meaning of those numbers very soon become meaningless, whereas 1/2/3 couldn't be any simpler. However, assuming we introduced something like this down the line, how would you expect stories to be ordered then because is a 1.2 more importan than 2.1?
+1
Hi Matt,
- I initially order stories during release planning: I often plan a minimum viable product release first and then a series of other releases later. Our releases or "waves" are between 1 and 3 months. As an example in our last project the first release included registration through the existing text interface and a number of other features. Release 2 included some more features and improved registration where the user didn't have to leave the app. It's both the registration theme but release 1 contains bare bones while the theme is improved in release 2.
- A priority field might work although I always find it difficult to remember other stories' priorities when what I really want it just a ranked backlog.
- I'd love to be able to toggle two backlog views: by theme and by release
Cheers,
Sandy
Thanks for the feedback Sandy.
Matt
We'll work up some ideas internally to see what works best and hopefully implement something within the next few months at most. As soon as we have something to show, we'll be sure to send you an email to check it out.
Matt
Not an easy one, filtering and ranking is always useful but I believe you'll find that most people have different needs as they work differently, also adding another field is adding yet more clutter to the main form. However I do appreciate that if you have a long backlog and need to prune it constantly having to re-order things manually is not ideal, you could do it via the Excel export but then it's never live and you have to re-do it every time something changes.
I guess we could add a ranking field (they can then call it whatever they want) and then have two options:
- Allow users to order stories by rank or by original order (set manually)
- Or create a new 'filter' functionality that brings the backlog in another view where you can filter stories by rank, manually or other parameters (we could use current ones and allow for expansion down the line), this would mean that you'd keep the backlog ranking as it but for different views of the backlog the user would go into a new area to manipulate the backlog and extract the information they need.
What do you think?
I think you're right, it's going to have to be something along the lines of what you have suggested.
When viewing the backlog in normal editing mode or in Sprint mode, you could have the choice to: Order by Theme or Order by Story. When in order by story mode, you could then have a an option to sort (or resort) the backlog by the importance field. We could then ask the user to choose their sorting method i.e. alphabetical, numerical, or possibly even factor so for the example where impact & priority is used, the code 1.1 could be calculated as 1x1, 1.2 as 1x2, 3.2 as 3x2 etc.
What do you think of that?
Hi,
My main desire is to keep things simple. They might be really smart ideas but I don't actually need a calculation based on impact and priority or many different filters or ways to order my backlog alphabetically.
I only want to see what's next - both from a themes point of view and a user story point of view. Drag and drop would be my method of choice so I don't have to fiddle with number sequences (the field if needed for implementation could be invisible).
I hope this is helpful ...
Best regards,
Sandy
Great, we like simplicity, a lot.
Thanks for the feedback.
We'll keep you posted once we introduce something to address this need.
We've been "working around" not being able to have the stories in an independent order by coloring the items we want for the next sprint yellow. But I don't think I would want stories independent of themes. The theme ordering is helpful in that it allows us to make sure we've gone through the themes in order of most important themes first, so that we don't forget to grab at least one story from the biggies.
I know other companies may prefer to organize them in other ways...We have a backlog per product, not project. This means that we have a huge number of themes, as in when sorting my list of themes scrolls. Maybe others have one per project so the long list view would be meaningful, but for us the long list option would just be messy. I can't imagine dragging and dropping individual stories to set the priority every time. The more I think about it, the more I like the theme ordering.
This may also be partially about how themes are organized. We have multiple themes per functional area. Quiz Refactor Phase 1 and 2 for instance. That way the refactor can have multiple priorities on the list, based on the two groups of stories.
Just my two cents, and some different ways to use the software that may help answer the pain.
I know other companies may prefer to organize them in other ways...We have a backlog per product, not project. This means that we have a huge number of themes, as in when sorting my list of themes scrolls. Maybe others have one per project so the long list view would be meaningful, but for us the long list option would just be messy. I can't imagine dragging and dropping individual stories to set the priority every time. The more I think about it, the more I like the theme ordering.
This may also be partially about how themes are organized. We have multiple themes per functional area. Quiz Refactor Phase 1 and 2 for instance. That way the refactor can have multiple priorities on the list, based on the two groups of stories.
Just my two cents, and some different ways to use the software that may help answer the pain.
+1
Thanks for the feedback Shaunty.
BTW. I'm not sure if you've seen, but we've recently introduced a feature so that you can move a whole theme to another backlog. Based on what you've mentioned above, this can be useful if you start a new backlog for say Phase 2, but want to move a group of stories to this new backlog.
All very useful when we consider ways to allow people to work in the ways they are used to. I think we might simply have two views, one with themes, and one without, but all stories must be assigned to a theme regardless (as that is how we work now), however we may allow you to view the stories in their own order outside of the theme they are attached to. Hope that makes sense.
Anyway, when we launch this feature we'll let you know and would appreciate your feedback.
BTW. I'm not sure if you've seen, but we've recently introduced a feature so that you can move a whole theme to another backlog. Based on what you've mentioned above, this can be useful if you start a new backlog for say Phase 2, but want to move a group of stories to this new backlog.
+2
Consider two views, a hierarchy view and a categorized view. In the hierarchical view the priority is stack ranked. In categorical it is grouped by what you are referring to as a "theme". If users could toggle between the two views and allow drag and drop prioritization in hierarchy view and then automatically assign priority in the categorical grouping based on the hierarchical priority, that might be an improvement.
Hi Curtis
Matt
Thanks for the feedback, we are working on a solution. We'll post into this thread as soon as we get something live.
Matt
Svar
Planlagt
Hi Sandy
Thanks for the feedback. This is an issue we're actively trying to address, but I'm not sure we've quite figured out the perfect way of fixing it yet, and hence not implemented it. Hopefully you can help by answering a few questions:
- When do you actually need to order these stories? The reason I ask is that grouping stories by themes seems to be a popular feature for most users, however I understand some stories in some themes may be higher priority than another theme higher in the backlog. When would you actually envisage ordering the stories and viewing the stories in order of importance?
- If we added a priority field to each story so you can enter a number say between 0 and 100, would that suffice? In the sprint view, one could then order by backlog order or priority order.
- Do you think it's necessary to have two views for the backlog, one by theme, and one which is simply a long list that you can re-order?
Thanks,
Matt
Matt
This is also a feature I would definitely put on prio 1 :-)
Themes for me are big blocks, that help me discuss the features with the customer, help me brainstorm and put them in a big functional context.
But these themes-blocks are too big to put them one after another. That is just waterfall again.
I would like to be able to put a weight factor in front of each story. This could be a free integer field. Just let me fill in a number (I can choose big numbers to leave space for incoming stuff etc) and make it possible to sort on that level. This would result in a view with all stories ordered on prio level and with the theme field just as an info field.
For the moment I too am coloring the user stories, but this really is not a practical way (+ I want really one clear order, not 20 items with prio 1)
Voila, hope this is a bit clear. Always ready to give some extra clarification of needed :-)
Hi Geert
We are going to introduce this feature soon, however we are erring on the side of not including prioritisation numbers, but instead letting people order the list by dragging stories up and down. The reason we are going for this option is because a numbering system becomes difficult to use with time. For example, you start with high priority items as 1, and low as 100 (or vice versa depending on how you score items). Then later you may decide you want a new item as more important than those number 1 items. You now need to renumber the old number 1s to make space for the new number 1. This problem then effects all number 2s, and the problem carries on. Hence, we think a drag and drop solution would be preferable as numbers never need to be manually changed. What do you think?
This is an important consideration. We've found themes in easybacklog to be mostly unusuable as envisioned exactly because of this. A backlog should have exactly one ranked order, but themes make a mess of that.
To that end, how we HAVE found themes useful is to think of them more like milestones - essentially units of time. Since story priority must equate to time, then it's natural to move stories in and out of themes based on units of time.
You could use themes using this idea following any logical grouping of time you felt was appropriate, e.g. M1, M2, M3 or alpha, beta, production, or Q1, Q2, Q3 etc.
Thanks for your feedback Taylor. We agree with you, we just need to schedule in the time to address this issue and allow prioritisation of stories separate from their themes.
I don't suppose there's any progress on this is there? I'd like to prioritise my backlog my user story rather than by theme but this doesn't appear to be possible still.
Unfortunately not Michael, we've been bogged down on other things. Sorry :|
Hi Matthew
nothing new about this feature?
it's very important to make independant the stories from the Theme to rank them in the backlog
thanks
nothing new about this feature?
it's very important to make independant the stories from the Theme to rank them in the backlog
thanks
+1
Hi Michael
To be honest we're struggling to make the time to add new features as opposed to simply maintain the site and improve critical functionality. This is largely because we have no revenue stream for this service as we provide it for free. I think in order to best serve our users we should invest some money but this would require us to start charging. Do you think you would be willing to pay say $10-$20 a month per user for easyBacklog? If so, we might seriously consider refocussing and investing.
Thanks,
Matt
To be honest we're struggling to make the time to add new features as opposed to simply maintain the site and improve critical functionality. This is largely because we have no revenue stream for this service as we provide it for free. I think in order to best serve our users we should invest some money but this would require us to start charging. Do you think you would be willing to pay say $10-$20 a month per user for easyBacklog? If so, we might seriously consider refocussing and investing.
Thanks,
Matt
Hi Matthew,
We would also be really happy to be able to use this feature.
It's not always the case that we can say a whole theme goes before another one. This leads to awkward roundabouts such as duplicating themes, which doesn't work so well.
About your latest post, I guess it would be a possibility for us to pay for the service, although we did look for free tools when we thought about taking our backlog online (which is why we started using easyBacklog). I totally understand your point, but it would depend on the options available to us at the time of making the decision.
We would also be really happy to be able to use this feature.
It's not always the case that we can say a whole theme goes before another one. This leads to awkward roundabouts such as duplicating themes, which doesn't work so well.
About your latest post, I guess it would be a possibility for us to pay for the service, although we did look for free tools when we thought about taking our backlog online (which is why we started using easyBacklog). I totally understand your point, but it would depend on the options available to us at the time of making the decision.
To me this seems like something that should be done when they get put into the sprint.
Kundesupport af UserEcho
Matt