I'm not sure I completely understand what you are asking for.  As you have said, currently stories are grouped under theme, so the theme ordering takes precedence over story ordering.  We are in fact considering an alternative view where you can order stories independently of themes, but we've not consolidated how this will work yet, so have not implemented this.  We are working on a solution though, so we will keep you posted on this.  You can see the discussion on this at http://easybacklog.userecho.com/topic/94379-drag-and-drop-ranking-of-backlog-independent-of-themes-eg-t1s1-t2s2-etc/

However, could you elaborate on what you mean by using tags so that I can understand that requirement?

Matt

Ok, I am surprised, I thought the flow of information would have been the other way round, from Jira to easyBacklog.  Interesting to hear your use case.

So just to be clear, you are saying that requirements come from various sources, and you add them to easyBacklog and cost them.  When they are ready to be put into a sprint, that is when you assign to Jira, and right now you have duplicate work to do because you have to manually enter the stories into Jira?  Are you managing your sprints in Jira then and not using easyBacklog sprint functionality?

Other than pushing a story from easyBacklog into Jira, how would you envisage any information being reported on from easyBacklog.  Surely you would use Jira to report on progress if that is where you are putting the wor?

In regards to your import, see http://easybacklog.userecho.com/topic/96806-as-a-user-i-want-a-bulk-upload-facility-so-that-i-can-import-user-stories-from-a-spreadsheet/.  This is a daunting task.  What format is your data currently in?  Perhaps I can help write an import script for now until we have a better solution in place.

• When a story is assigned to a sprint it becomes locked.  As such, we would need to manage locking of stories between backlogs, and stop users from reassigning stories to multiple backlogs.
• Total project story points would now be variable based on the stories you have in your backlog and in your sprints.  As it stands now, burn up charts and burn down charts are based on story points in the current backlog over time.  Allowing users to add stories outside of the backlog would mean the effective overall story points would increase yet the backlog would not show this.
• One of our key features is backlog snapshots so you can compare the state of a backlog at particular points in time.  If we allowed stories from other backlogs to be part of this backlog's sprints, then would we show that in the snapshots?  It would seem silly to because they're not really part of this backlog, yet they are effecting the points to complete.

Or, alternatively, would it be useful instead to simply allow you to import stories / themes from other backlogs (not move, make a carbon copy), and add them to the current backlog?  That way you could give product owners read only access to the overall backlog so they can see their stories and when/if they are assigned to sprints, but let them build up their own backlogs that you can import from.

Finally, another alternative may be instead to simply run separate sprints for each product as each product should really be tracking it's own burn down / burn up, and progress.  Whilst I appreciate your teams may operate as one, for each week you can assign the expected velocity of the team on that project, and you could simply manage effort allocations for each externally with a spreadsheet so that you know your team is for example spending 10% of their time on product A, 20% on product B, and the remainder on product C.  That way each product is managed as it should be, as a single product, and all reporting will be accurate.  Assuming that approach would work, would you not then possibly just need a centralised reporting facility so that you can see progress across all projects (something we are considering now anyway)?

Would be great to get your thoughts on this.

Matt

It sounds like how you are trying to get easyBacklog to work really does not work well with what easyBacklog has been designed for.  It has just not been designed to run centralised sprints across multiple backlogs, and that is really what you are trying to do.  

Whilst the workaround solution of moving stories into the central backlog kind of works, this is not really a viable solution if you intend to move stories back into the user's backlogs as stories are locked into a backlog one you have assigned them to a sprint.

What we will do is think about how we could accomodate this need in the future, and figure out the cost and impact of this on other customers.  I'll add it to our backlog, but until other people ask for similar functionality, this will unfortunately remain low down on our backlog priorities.  I hope you can understand that we need to focus on building out the product features that most people are asking for and need.  I am sorry in this case we don't have an immediate solution.

Matt

Thanks for the feedback.  When you say synced, this can be done in many different ways.  Can you explain what you mean by this?  What is the flow of data and for what purpose?  If I can understand a lit more about how you envisage this working, then I can see what we can do to accomodate this.

Thanks,
Matt

As it stands, you cannot build sprints from other backlogs.  Whilst I can certainly see a use case for this, this is quite niche functionality and would change the product quite significantly in that sprints will be divorced from backlogs.  This would effect everything.  What you can do however is let people work in their backlogs, and then move their stories to a central backlog when they are ready.  This can be done by using the move theme feature (tool icon next to a theme).  You could then allocate each user read access to the central backlog, and full access to their individual backlogs.

Do you think that would achieve the same result?

This is unfortunately an interesting problem.  The reason you cannot select text is intentional because the primary action within this view is to drag and drop items.  If we enable the selection of text, then when you try and drag and drop you may unintentionally end up selecting text instead of dragging and dropping.  To be honest, I think allowing text to be selected would be at the detriment of most users.

However, saying that, we're planning on introducing a feature whereby you can edit stories from within the sprint view.  When we introduce this, you could click on the edit button, select the text, and close the edit window.  Would that work for you?

Matt

One solution would be to export in Excel format and print from there.  Good point though, we've not really had anyone ask for this before, so perhaps we need to give users an option when going to print.

Matt

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 for the feedback, we are working on a solution.  We'll post into this thread as soon as we get something live.

Matt