Vos commentaires

Thanks for the feedback Adam.  Are you saying that even if we had a prioritisation view independent of themes where you could prioritise stories, you would still prefer to have a separate field for importance for each story?
Hi Ian

I understand what you are after, that makes sense.  When we introduce releases (a little way off), then we will allow a user to assign a story to a sprint or a release.  Thus if you want to filter by current release only, you will be able to do that easily.

Thanks for the suggestion, however I thought it would be worth noting that we're not planning releases for a little while yet, so unfortunately you will have to deal with a big backlog for now.  Sorry!

Matt
Hi Mike

I completely understand where you are coming from, and I can assure you that the decision to introduce this has caused countless arguments amongst us.  In fact, if we had to put it to vote, we'd probably not do it because the majority of us want to keep it true to its original ideals of being a great backlog management tool for Product Owners and Scrum Masters.  However, we do listen to our users, and we've had so many people ask for this feature that it's become something we simply cannot ignore.  

In terms of how we intend to implement it, this is where we are putting in a lot of effort.  We're not going to build another Mingle, we're going to build something that is somewhat opinionated, follows best practice, and above all is simple (no MQL or any of that crap). It will also just be an add-on feature for those who want it, and will be a simple setting that can be switched off/on as you have suggested.  Again, we know why you don't think we should offer digital scrum boards, and as a rule of thumb we agree with you, however lots of people have many valid reasons for needing digital scrum boards, and if we don't offer it they unfortunately have to use two products which is not ideal.

Thanks for your feedback.
Matt
Hi Mike

We would consider adding sprint names, however there are some practical issues that would need to be considered.  Your comments and thoughts on the below will help guide us to finding a solution if there is one that will work for our users:

* If we add this field, it obviously means for users who don't use sprint names they have an extra field to consider.  We'll think about how best to deal with this from a UI perspective, perhaps sprint name is auto-filled based on the number, and you can simply change it if you want.
* The tabs for sprints will probably have to remain as Sprint 1, 2, 3 etc. however when you roll over them perhaps we could show the full name, and when you view the sprint itself we could show you the name.
* In reports, we could possibly show the sprint name, but once again may have to revert to sprint IDs and have the full name on roll over.
* In the backlog view, there is no way we have more space for the sprint tabs to contain the full sprint name.  As such, we'd again have to have the full name available on roll over.

Your thoughts appreciated.

Matt

Glad you like easyBacklog, thanks for the feedback.
Great, glad that works.  Shout if you have any other ideas, happy to consider them if they improve the user experience.
Hi Roger

On your first point about the open/collapse not remembering the stories that are filtered, we have fixed that bug now.  Our first stab at writing the filtering engine for the view was a bit rudimentary, so we've completely rewritten it now and I believe is way more robust.  Shout if you run into any problems.

We have also now implemented the feature so that your personal preferences in regards to your filter and collapsed themes for each backlog are remembered.  Please can you tell me what you think?  We really like it, thanks again for the suggestion.

Matt
Hi 

I believe we have now fixed this issue.

Would you mind telling me if it works OK for you?

Thanks for the feedback and telling us of this problem.

Matt
Hi Roger

Can you take a look at the site now as we have implemented a marker for the current sprint.  We tried a few variations, but ended up with this option as we think it's clear which sprint is current (white text with shadow), and clearly all sprints before are complete, and all after are not.

Can you tell me what you think?

Matt