Feedback on suggestions

[team tisri]

I couldn't help noticing the number of times someone makes a suggestion and is told "it's in the backlog". I realise Groundspeak isn't a huge software house and doesn't have limitless resources to throw at programming issues but over time the standard approach does come across as little more than "thanks for the idea, just don't expect it any time soon". It's also frustrating when, as someone in one of the suggestion threads mentioned, things like the favicon and general "look and feel" get updated while useful features remain in the backlog.

 

If there is some way the powers that be could provide some form of useful feedback so people making suggestions know whether they are likely to be implemented and maybe even an approximate priority it would certainly show a better level of engagement with the community. As it stands it does often seem like the only purpose of this forum is to provide would-be competitors with a list of things their customers are likely to ask for.

 

I appreciate that "graphic designer" and "software developer" are totally different roles but do sometimes wonder whether there are too many of the former and too few of the latter. I'm also not expecting ideas to generate a response of "we'll do that on August 14" but it does seem like there's little point having a forum like this one when so many ideas turn out to be "in the backlog" with no idea of when, or even whether, they will ever see the light of day.

 

Even being told "nice idea but it won't work with our architecture" is better than "in the backlog". The vote-based Feedback system of old seemed like a good idea because it highlighted what larger numbers of people wanted - for all 1000 votes represents a small fraction of the global caching community it shows the idea is more popular than the one that got 3 votes.

[+tozainamboku]

Unfortunately the word "backlog" is a bit of jargon and has no meaning to most people.

 

In agile software development it refers to a list of prioritorized requirements that the development team works on. In some forms of agile developement a Product Owner manages the backlog, adding and removing items, as well as adjusting priorities. The Product Owner is supposed to represent various interests including management, marketing, and the end users. Inputs from these groups drive what is in the backlog and how it is prioritorized. In some forms of agile development, the developement team works in sprints (short periods of 2 to 4 weeks) and is responsible for deciding how much of the backlog they will commit to finish in this sprint. Often an item in the backlog reaches the top of the list and the team feels this is too big or not well enough defined to be able to commit to it. They will work with the Product Owner to break up the item into chunks that can be managed in the current sprint. Other parts may be reprioritorized to be lower down in the backlog.

 

These agile methods work best with small teams of developers (including graphic designers, testers, and software developers). While there is work in progress to make these methods scalable so that additional groups can be added to work on larger products, many organizations find that adding people or teams just makes more work and slows down the individual teams.

 

When a Groundspeak lackey says something is in the backlog, I assume they mean that this is a requirement that is on the "To do" list: that it is being actively managaged by a Product Owner who sets its priority, and that the development team is working on just the items at the top of the list that they have comitted to completing in the current sprint. There is no schedule for when the items in the backlog will get done because the expectation is that priorities change and that new items, some with higher priorities, are added all the time.

[+J Grouchy]

So, instead of vaguely saying "it's in our backlog"...what's so hard about just saying "it's on our to-do list, but we can't provide concrete information on when it might be implemented"?

[+niraD]

The vote-based Feedback system of old seemed like a good idea because it highlighted what larger numbers of people wanted - for all 1000 votes represents a small fraction of the global caching community it shows the idea is more popular than the one that got 3 votes.

The problem with the UserVoice system was that it gave some people the idea that they could expect ideas with lots of votes to be implemented quickly. That isn't the case, any more than it is the case that ideas posted here with lots of positive support will be implemented quickly.

[Moun10Bike]

niraD is exactly correct - the user feedback systems we used previously were not a good fit for our business and community. We were quickly inundated with many more requests than we could possibly handle, and voting led people to develop unrealistic expectations as to whether and when a given idea would be implemented. That doesn't even address the issue of "running up the score" in which certain items that most would consider inconsequential would get a grassroots drive behind them and suddenly be catapulted to the top of the "hot" list. To this day, when someone asks me why UserVoice was shut down, I answer somewhat tongue-in-cheek, "a souvenir for Guam." That request was in the top 5 when we closed down the forum, ahead of such things as better handling of corrected coordinates, correcting the time stamp issue, et al.

 

I know that everyone wants improvements, and we do too. However, we have limited resources and the senior management team has to balance the needs of the community, the business, and the employees when determining where to direct those resources. This means that a lot of great ideas have to seemingly languish for extended periods. When we do not provide an answer as to when we can expect to see a given implementation, it's usually because not even the top levels of management know. See toz's explanation of the Agile environment for an explanation of why that is.

 

The best that I can promise you is that when good ideas come in, we will make every effort to get them into the backlog - or to-do list, if you prefer - so that they are on the radar when it comes to planning.

[+cerberus1]

Thanks for the explanation.

Maybe this would be a good sticky thread. Comes up often enough (usually in other threads).

[team tisri]

niraD is exactly correct - the user feedback systems we used previously were not a good fit for our business and community. We were quickly inundated with many more requests than we could possibly handle, and voting led people to develop unrealistic expectations as to whether and when a given idea would be implemented. That doesn't even address the issue of "running up the score" in which certain items that most would consider inconsequential would get a grassroots drive behind them and suddenly be catapulted to the top of the "hot" list. To this day, when someone asks me why UserVoice was shut down, I answer somewhat tongue-in-cheek, "a souvenir for Guam." That request was in the top 5 when we closed down the forum, ahead of such things as better handling of corrected coordinates, correcting the time stamp issue, et al.

 

I know that everyone wants improvements, and we do too. However, we have limited resources and the senior management team has to balance the needs of the community, the business, and the employees when determining where to direct those resources. This means that a lot of great ideas have to seemingly languish for extended periods. When we do not provide an answer as to when we can expect to see a given implementation, it's usually because not even the top levels of management know. See toz's explanation of the Agile environment for an explanation of why that is.

 

The best that I can promise you is that when good ideas come in, we will make every effort to get them into the backlog - or to-do list, if you prefer - so that they are on the radar when it comes to planning.

 

The terms make more sense now, so thanks for the clarification.

 

Managing expectations is obviously an issue with any form of user feedback but with a unified list it seemed that at least requests were in one place, people could vote on requests to give at least some gauge of popularity.

 

Even so it still often seems that things get into the "backlog" and vanish - an obvious example being the suggestion to let anyone mark trackables as missing which was made here somewhere north of two years ago. It's not my business and I fully appreciate I don't set the priorities, but I have to say I'm surprised at the apparent lack of inclination to do anything with that one.