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.
Sometimes functionality implemented by user story is too big to be implemented within a single sprint. In this case we would like to create two user stories and to mark a second one to be dependent on the first one. Using order of stories inside of theme partially solves this problem, but not completely. Sometimes we have story that is dependent on a couple of other stories, or dependent on story from another theme..
Whilst we certainly appreciate that sometimes this occurs, we are not sure the added complexity of supporting linked stories would benefit most users most of the time. Do you not think that simply using some naming structure would solve this rare requirement?
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.
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