Hi I have found a typo in the api documentation.
Created_at item attribute at the Sprint object: it's duplicated and one of them refers to the completed_at attribute.
Great API!, using it now with Jupyter and Pandas to explore team metrics.
I am developing an application to import some of our Backlogs, Themes, etc into a Database for further reporting purposes.
But i'm running into troubles as the "created_at" attribute of some SprintStories contains "null" as you can see here:
As the document does not state the attribute "created_at" to be nullable, I'm wondering whether this may be a bug?
Also there is a "bug" in the documentation of the Sprints (http://easybacklog.com/api#sprints).
In the list of available attributes on the left, you have listed "created_at" twice.
One of them should be named "completed_at" I think :)
Thanks for your help!
Thanks for pointing this out. This is indeed very odd, as the business logic dictates that whenever a record is inserted into SprintStories, the create date should be set. We'll need to look into what is causing this, apologies for the hassle.
We'll get the Sprint docs updated too, thanks for spotting that.
When entering 50/90 estimates the error message that appears when the 90 value is less than the 50 value is incorrect - it says the 90 value MUST be less than the 50 value when in fact the reverse is true.
When I accidentally entered a value of 1 for the 90 estimate after entering 5 for the 50 estimate an error message appeared stating that the 90 value must be less than the 50 value. The wording of the message needs to be corrected to state that the 90 value must be greater than the 50 value.
This issue is now fixed.
Thanks for pointing this out. If you come across any other issues please shout.
As a user I would like to set "Points" for each story via a drop-down menu so that I don't need to memorize the fibonacci sequence.
When considering a sprint, time and points are approximately related and the coefficient is the velocity. When considering several sprint, the relation between points and time is more accurate.
But if you take one user story in particular, it's not at all related. I would like to be able to have a pretty complex user story that doesn't take that much time, or (more common use case) the contrary : a user story that is not at all complex (points) but require a lot of time to be completed.
Unfortunately we don't want to introduce two systems for time tracking. You are right, it is possible to have complex stories that are quick to fix, and vice versa, but for the purposes of this backlog, the points are more a representation of effort required and as such correlate to time. If we introduced a new field, this would only complicate things further.
Each month we would like to export the number of story points that each team member has closed within that month. None closed tasks shall continue over to next month. We could also do this export at end of each sprint.
Hi there, when I try to make a snapshot I get an error message. The snapshot isnt taken. Previously it was duplicating the whole backlog and giving it the name of my snapshot
I am sorry to hear that. We have not received any notifications of errors on our side which is odd.
Is the problem still happening? If you can recreate it, please send us the URL to your backlog at email@example.com and we'll look into it.
Sorry for the inconvenience.
It would be helpful to display both the sprint start date (which is displayed) and the sprint end date at the end of the sprint page (which currently is not displayed)
Customer support service by UserEcho