Welcome! This forum has a treasure trove of great info – Scouters helping Scouters! Just a heads up, though - all content, information, and opinions shared on this forum are those of the author, not the BSA.
There are a large number of feature requests on this page. Some of them never even received a response. Are all of these requests being forwarded to the developers? If not, how do we know which ones are, and which ones aren’t? And for that matter, what is the decision matrix to determine this?
The SUAC members try to respond to each request but some may have been missed as we are all volunteers.
The BSA does not make the backlog public nor provide estimated completion dates for new features. All we are allowed to do is indicate if a request is in the backlog. The BSA uses feedback from the SUAC along with knowledge of its internal needs to determine the priority list. Since there are limited resources (development dollars and time) and competing requirements the priority list does not always reflect the desires of any one group of stakeholders.
@edavignon Thank you. I understand that everyone is volunteering and that you can only indicate if it is on the backlog list. My question is do the items that aren’t on the backlog list get passed along to BSA/developers for them to consider for placement on the backlog list? Some of the requests receive comments in the spirit of “passed along to the developers” and other requests don’t.
Well stated. There are features that we already know will not be done, such as tracking adult awards and local Council awards. Those aren’t going to make the backlog list, even though they get requested from time to time…
Speaking for myself only, I read every single post, but I sometimes don’t comment if I feel I’m not the best person to respond. Of course, if we all do that, we run the risk of having no responses at all.
Some (like the accent mark for one of my scouts) might never get fixed
As for feature requests, open the weekly update email like a Christmas stocking - you might get something awesome that you didn’t even know you would love.
In RSVP reminder emails for calendar events, it would be nice if the email would contain the current RSVP status of the invitee(s) that the email is sent to, so I don’t have to go double-check my RSVP status every time I get a reminder.
How about a list of items that are on the backlog and those that have been requested and will not be considered?
Two things I would like to have added
1)be able to differentiate between a Troop Quartermaster and a Patrol Quartermaster as well as other positions.
2)Be able to enter troop, summercamp awards. Simple text is all we need but please dont force us to keep two sets of books.
You really have done a fabulous job with scoutbook. I hear of people switching to it in droves. We taught it at our University of Scouting. You should be proud of all you have accomplished but please keep going.
Microsoft and the OA Lodge Master system have a more open system. Users can suggest and upvote features. Honeywell software does a similar thing and allows users to both suggest and the direct a small budget of development dollars to those user suggestions.
The BSA will not publish the backlog. The most we are permitted to say is if a suggestion is on the backlog. We cannot predict if or when items in the backlog will be scheduled for development.
Scoutbook already lets you designate a Scout as the Troop or Patrol Quartermaster. When you create the Quartermaster leadership position select N/A for the Troop Quartermaster or the Scout’s patrol for the Patrol Quartermaster.
There are no plans to add custom awards to Scoutbook at least until all national awards are supported.
So, if I’m reading the responses correctly, the SUAC members decide whether a feature request should be passed on to the development team. If SUAC thinks that something is “worthy”, as it was put, it will be passed along to the developers. At that point, the developers, in consultation with BSA, will decide what gets put on the backlog list.
I’ll need to make sure that the SUAC likes my ideas.
That is not what we are saying. Most requests are added to the backlog. Some are already in the backlog. Others have previously been considered by the BSA and rejected. We try to answer every post for a new request, but we are volunteers and some may get by us because we are busy with our work or personal lives that do not involve Scoutbook.
If there are features that were requested that do not have an answer and you would like to know if it is in the backlog or not, point us to them and we will do our best to answer.
Many requests receive the “on backlog”, “BSA won’t do it”, or “forwarded to developers” responses. However, some just die with no closure.
I’m curious as to the status of this request Remove “Adult Partners” from Pack’s Leader Roster. I was told it isn’t a bug, I concurred that it isn’t a bug and that’s why it was placed in feature request along with details as to how I’d like it to function. Then the topic died after 7 days with no wrap up.
Yes, but software development is not a democracy. Roadmaps are one way of handling customer/stakeholder relationships, but not necessarily a good way.
This recent short post from Basecamp, Options not Roadmaps, is a nice reminder of the downside of roadmaps. They’re a small(ish) company that makes their money providing features people will pay to use, but they don’t use roadmaps because they feel the downsides (both in terms of missing customer expectations, and inevitable developer guilt) are not worth it.
I love roadmaps and backlogs too… but they quickly become overwhelming and priorities can change quickly, sometimes daily. Personally, I’m glad I’m not on the BSA development team trying to wade through all the issues and requests (though I’ve sometimes foolishly thought about it )
Without being open about the process people will continue to request the same features over. Also, the process many software projects use is an upvote system to gauge popularity of feature or help determine the severity of a bug.
To move agile, software developers and product owners need quality feedback from customers, unfiltered.