Uw opmerkingen
Hi Roger
You have some great ideas there. We are thinking of introducing releases, which should solve your sprint archiving problem. The way releases will work is that you can put completed sprints into a release and you will no longer see those sprints in the tabs at the top, you will only see releases at the top, so you will have far less tabs.
In terms of your ideas about showing the current sprint, and which ones are complete, I think this is brilliant. We will either introduce colour coding so you know which ones are complete and which one is current, or use icons. We'll have to play around with this to see what works best. But either way, we'll definitely do this, nice idea.
When we get this working I'll drop you a line to get your feedback.
Matt
Hi Roger
Apologies, but I am not entirely clear what you are after. Are you saying that you think the current sprint should have a marker to show that it's the current one when in backlog view? Is that so when you are looking at the backlog, you know which stories are currently being worked on?
Would a simple marker suffice, or do you need more than that?
Matt
Matt
Hi Ian
Thanks for the feedback. We are really doing our best to cater for everyone, however that does sometimes mean we can't solve all problems for all people. However, if I can understand a bit more about what you're trying to achieve, then I hope I can find a solution.
In response to your points:
1. Managing features by sprint: We are considering adding releases, this has come up a few times from users. However, we are mostly being asked for releases as a way to group themes together so that any stories that are assigned to a theme, which in turn is assigned to a release, is grouped by that release. And once a release is marked as complete, then all the stories for that release are no longer shown in the main backlog. What are you trying to achieve with releases so that I can understand why you need releases?
2: Risk & business value: This request has come up a few times, but we've not yet resolve this unfortunately. See http://easybacklog.userecho.com/topic/83641-add-business-value-field-theme-importance/ and http://easybacklog.userecho.com/topic/94379-drag-and-drop-ranking-of-backlog-independent-of-themes-eg-t1s1-t2s2-etc/. If you read the latter one, this is what we are planning on implementing, the ability to specify the order of your backlog independent of themes. Whilst this won't explicitly add risk / business value fields, it will allow you to prioritise independently. Would this solve the problem for you?
Thanks for the detail. We'll look into this shortly, however we are intending to migrate people onto WebSockets with a fall back for older browsers only, so this will solve that problem anyway. As soon as we either implement a fix or update the library we'll be sure to let you know. Apologies for any inconvenience in the mean time.
Hi Chris
Thanks for the feedback. I understand what you are after, let us have a play around and see what can be done on our aide I satisfy this need. We'll revert with some ideas after our next planning meeting.
Thanks again, hopefully we'll find an easy solution shortly.
Matt
Thanks for the feedback. I understand what you are after, let us have a play around and see what can be done on our aide I satisfy this need. We'll revert with some ideas after our next planning meeting.
Thanks again, hopefully we'll find an easy solution shortly.
Matt
Hi metacentric
Thanks for the feedback.
Realtime.easybacklog.com is a real time long polling (works in all browsers whereas web sockets don't currently) that ensures that when two or more people are simultaneously making changes to a backlog they are notified of that. It's run from a separate domain to the main execution of web and AJAX requets an in all of our tests so far has not interfered with the web application at all.
Can you describe the problem you are experiencing? Also, what browser are you using on what OS?
Thanks,
Matt
Thanks for the feedback.
Realtime.easybacklog.com is a real time long polling (works in all browsers whereas web sockets don't currently) that ensures that when two or more people are simultaneously making changes to a backlog they are notified of that. It's run from a separate domain to the main execution of web and AJAX requets an in all of our tests so far has not interfered with the web application at all.
Can you describe the problem you are experiencing? Also, what browser are you using on what OS?
Thanks,
Matt
Hi
Sorry for the slow reply.
I am sorry, but I am not really sure what you mean here. Can you explain how I can replicate this problem?
Matt
Matt
I agree Roger, we will optimise this.
Hi Roger
Apologies, but I am not entirely clear what you are after. Are you saying that you think the current sprint should have a marker to show that it's the current one when in backlog view? Is that so when you are looking at the backlog, you know which stories are currently being worked on?
Would a simple maker suffice, or do you need more than that?
Matt
Matt
Customer support service by UserEcho
Thanks for the suggestions and feedback.
Matt