Completed items are no longer backlog, so if the program is going to show only one number, it should be the size of the backlog (not including accepted items).
As a workaound, I will need to delete accepted items to get a correct number for my backlog (some have hundreds of items, if I have to export to Excel and filter to get a total backlog, it is no longer an easy backlog :-)
To be honest, I completely agree it should work like this. At present this is not the way the system works, but it something we will implement soon.
Normally in Scrum, the burndown chart is updated daily and visible to the team during the course of the sprint. It's used by the team and the scrum master so they can see if they are going off track.
it would be cool if i could use a quick search in the sprint view.
The Task i want to achieve is that i have a Story which i know very exactly (ID and the Text of the Story also, even aceptance criterias i know) because i took that story from another sprint.
Then i switched to the new sprint and have an enormous list of storys to the right.
Know i have 2 ways to find my story:
1. i scroll through the list but its a very very long list.....
2. i switch to backlog view and then pick the story from there
if i have an quick search in the sprint view it would be way easier.
We agree completely, we need a search for larger backlogs. It is something we are working on. I will drop you a line as soon as we have something you can use.
Thanks for the feedback, and we'll do our best to get something out there for you.
I am new to this site. easyBacklog does look very good to me, and seemd to be the solution that I need, However, I cannot open the .xls file that comes with the export. I am using libre office 184.108.40.206. I also tried on google docs.
What I am trieing to achive, is that I want a complete list of backlog items I can then print and put in my teamroom, so that everybody can see the backlog.
We did a major deployment today, and we came across an error that was causing failed requests with Roger. It turns out that his backlog was taking just under 6 seconds to render on the server, which is completely unacceptable.
Because of the urgency of this, we've devoted a fair amount of time today to finding a solution, and we've released some updates today that have brought that rendering time down to around 1.5s, so a 4x performance improvement. Whilst this is good, this is not good enough, and we'll be working to improve that even further.
Obviously there is client-side rendering performance as well, and we'll be considering Torsten's suggestions here too, to ensure the performance remains snappy even when working with large backlogs.
Sorry for the problems, and hopefully we'll have it lightning fast again even for our heavier users. I expect you'll notice the performance improvements already.
Customer support service by UserEcho