Sorry Mayuresh, we are aware of the issue and fixing it now.

Hi Josef

This issue has now been resolved.  In our tests, the stats query you were making before was taking around 28 seconds, it now takes 4 seconds.  There are possibly some further optimisations we can do, however considering the impact of this change, I believe it's unlikely this will be an issue for you in the future.

Please shout if you see any further problems.

Matt

Hi Josef

I have found the error in our log files, and it's a performance related issue.  The router is timing out and the process is being killed because it's taking too long to perform this operation.  We will replicate this issue internally and find a solution.  Thanks for notifying us of the problem, and sorry for the inconvenience.

Matt

Well actually I suspect asynchronous requests might make it work as you will be hitting our application servers harder concurrently.

We are not around today unfortunately, so will look into this on Monday.

Thanks,
Matt

Hi Josef

I'm sorry to hear you're having issues.  Oddly that error indicates that the problem is in fact at the router level, and not at our application level i.e. if we presented an error it would be in a suitable JSON format, and our error logging system would have notified us, which unfortunately it didn't.

I can certainly investigate, but could you answer a few questions:

• You mention you're using the API to retrieve a few backlogs, do you do this synchronously or asynchronously.  I'm just trying to get a handle on how many concurrent requests we may be dealing with as the stats requests are actually a little server intensive.
• Can you send me a sample `curl` command so that I can see how you are accessing the stats.  Obviously please exclude your API key ID.

Hi Roger

We have now both improved the performance of creating snapshots, and also pushed this into a background queue so that it does not time out.  When you create a snapshot now, it will be created a few seconds later by the queue, and your browser will respond immediately with confirmation of the queue being processed.

Please shout if you see this issue again.

Matt

Hi Mike

Total allocated points is a sum of the points allocated for that sprint based on the stories added i.e. what you have committed to deliver at the start of a sprint.

Total expected points is what you expect in a normal sprint to complete - i.e. this is either based on your velocity and team size, or it is specified manually for a sprint.

Total complete points is the number of points you have completed so far i.e. the number of stories marked as accepted.

Explicit velocity is present if you specify an expected velocity for the sprint as opposed to letting it be calculated for you.

Finally, please note that whilst some values appear to be strings such as "15.0", they are in fact decimals.  All values are decimals or integers.

We are considering support for releases, however at present we don't have this in our backlog of features to be added as we are not sure it is needed for most users.  However, thanks for the feedback as it helps us to understand what people need.  We will see if we can find a solution.

FYI, there is a related discussion at http://easybacklog.userecho.com/topic/93801-it-woudl-be-good-to-have-a-release-version-field/

Hi Sergi

We are in fact looking to document our 50/90 calculations better, so I will get back to you soon with that information and will address this post as well.

Thanks,
Matt

Unfortunately this is not a feature that is included right now, however you can use Excel filtering which is very powerful and easy to use.  Have you tried that?