New Feature Requests

New Feature Requests for Banno Products

Have a request to change functionality or add a new feature to our Banno products?

As we work within the products Banno offers and communicate with our customers to more fully understand how they are using our tools, we may come across instances where it’s determined a new feature would be useful or it would be beneficial to make changes to the way something currently functions. In this case, we can engage our product management team to review the idea, understand the use case, and help prioritize the work needed to build out the new feature or make the requested change to current functionality.

These ideas may come from our own teams using the tools internally or from our customers who are using the tools within their organization. In either case, it is important we fully understand how the product or feature is currently used, the context around the request, and the use case for the requested feature or change to current functionality. In other words, we want to ensure we know what we can do to make our products more useful, more intuitive, more impactful for those individuals using them. Before engaging Product, gather as much information as possible to make your case for the requested feature.

In order to more fully understand current product and feature functionality, our teams use the following resources to review what information exists today:

• Banno Knowledge-Base
• Banno Docs
• Banno Admin (Enterprise)
• Banno User Guides

Once you understand how the product or feature is expected to function, check current open issues in both the New Feature Requests project in Jira Service Desk, as well as the Product team project in Jira. This will give you a full scope of the work that the product team is currently managing and prioritizing and allow you to see if any similar requests already exist.

If needed, ask team members within your team’s or the relevant team’s Slack channel to see if others have received similar requests previously, or if they have any input to provide on use cases for the requested feature or change:

• Banno Apps Support: #team-support, #org-support, @support
• Banno Apps Implementation: #team-implementation, #org-implementation, @implementation
• Banno Apps Operations Team: #team-operations
• Banno Content Support: #team-tech-support, @cwas
• Banno Content Implementation: #team-project-coord, @pcs
• Banno Content Web Team: #team-webteam-talk
• Product Managers: #org-prod-mgmt

If you find an existing issue that satisfies the request

If you find an Inititative, Insight, or New Feature Request (NFR) which would satisfy the request, you should add the FI as a requesting FI and add comments if need be.

1. Open the Initiative/Insight/NFR and scroll down the “Linked Issues” section. Click the + button to add a new linked issue to the initiative.
2. Select “FI Request” from the Relates to dropdown
3. In the textbox, start typing the FI name. In the search results, you will select the Customer FI record that is blocked by this project. The Jira ID for Customer FIs start with “FI-”. If you’re unable to find the FI record, you should create one using the instructions below
4. Click the “Link” button. You have linked the Initiative to the Customer FI and designated it “FI Request”.

When Background Information has been Gathered

We will use Jira Service Desk to create an issue and engage the product team.

1. Create a new issue on the New Feature Requests board.
2. The issue will follow the outline for submitting new feature requests (found below), when created, to provide information for the product team to review and begin planning for potential future changes.
3. The original reporter will monitor progress on the original ticket as it goes through review and can follow progress of any linked tickets created to manage the feature request moving forward.
4. The original reporter and any other relevant team members will work with the product team through the Jira Service Desk ticket to provide initial information—as the review is happening—to ensure our product team has all the details to fully understand the request. * When the request has been reviewed, the product team will make one of the following determinations:

• Future feature consideration
• Existing idea
• Request declined

1. Once a determination is made, the original reporter will close the Jira Service Desk ticket.

• For requests approved for future consideration, the request will be tracked through the Jira Product board moving forward.

Further details on this process can be found under Tracking New Feature Requests.

Submitting a New Feature Request

1. Jira Service Desk and the Jira Product board should be searched prior to creating a new request. This ensures if the feature has been previously requested and already on the product team’s radar.

• All of our new feature requests handled internally should be routed through this repository, so we have a single place for Product to manage incoming internal feature requests.

2. When all background information has been gathered related to the new feature being requested:

• Create a Jira Service Desk issue to engage the product team.
• If there is a current task open related to the request and you have additional details to add, additional information can be added to the description and the additional details can be included in a comment on the standing task.
• If there are any discrepancies between your feature request and the related task already in Jira Service Desk or on the Jira Product board, create a new issue and add a link to any similar existing issues.
  • If the product team believes the issues can be taken care of in a single project, issues can always be linked together in the future.

Creating an Issue in Jira Service Desk

1. Access the New Feature Requests board.
2. Select Create (+) in left-hand panel.

• Each issue should cover only one concern.

3. Project: New Feature Requests
4. Type: New Feature Request
5. Summary: Title the issue using a succinct but specific description of the new feature being requested. Summary should begin with the product name (ex: ‘Mobile: New Feature being requested’ -or- ‘CMS: New feature being requested’).

• A very generic issue title makes managing the requests more difficult. Issues can always be renamed, if needed, as we understand more about the new feature being requested.

6. Description: provide a thorough description of the request for a new feature to be added. Explain where in our toolset the new feature is needed and include a use case for the new feature being requested.
7. Attachment: attach any files related to the request to help the product team better understand the need.
8. Product: indicate the product where the feature is being requested. More than one product can be selected.

• CMS
• Form Builder
• History
• Marketing
• Mobile
• Monitor
• Online
• People
• Reports
• Settings (Users/Groups/Logins)
• Support

9. Feature: indicate the specific feature where the new feature is being requested, within the product noted above.

• Bill Pay
• Cards
• Change User Info
• Documents
• Enrollment
• My Card Rules
• Password Management
• Remote Deposit
• SSO
• Stop Payments
• Transactions
• Transfers
• Travel Notices
• Zelle

10. Linked Issues | Related FI: if applicable, indicate the institution(s) requesting the new feature. Under Linked Issues, select Related FI, then search for and select each relevant institution found in the Customer FIs project or enter the FI’s issue key directly. If there are multiple requesters, include all institutions who have requested the feature. Note: Institutions are synced regularly from the implementation status sheets and can be searched by institution name or Company ID.

• Institution Name: if you are unable to find the appropriate institution from the Customer FIs project, indicate the name of the institution(s) requesting the new feature in the Institution Name field. If there are multiple requesters, include all institutions who have requested the feature.

11. Linked Issues: select relates to, then link any other open issues related to the new request to provide context and background information for the product team, if applicable.
12. Product Manager: this field can be left blank. It will be assigned automatically, once created, based on the Product + Feature selected.
13. Select Create: this opens the issue in the New Feature Requests project in Jira Service Desk and creates a link that can be used to track progress and as a reference point for discussions with the product team.

Tips on Linking Issues

When creating an issue, the linked issue field searches only your recent history or allows you to enter the issue key directly. If you are having trouble finding the issue you are wanting to link, skip this step and create the ticket. Once created, you can link issues directly from the open ticket, and this will search all open Jira tickets, rather than only your recent history. Direction for linking issues can be found in the Using Jira Service Desk guide.

Track New Feature Requests once Submitted

Once an issue has been created within Jira Service Desk, the product team will review the request. Requests that make their way through review will be added to the Jira Product board for the product team to track and plan for future projects. Once the request has been reviewed by Product, the Jira Service Desk issue will be resolved.

Product Management Review Process

The product team will make a point to sweep through requests coming through the New Feature Requests board on a regular basis. Each request will be reviewed, and the product team will ask any relevant questions on the original ticket to further understand the request. The product team will work through their review of each request individually, and each request will result in one of the following determinations: future feature consideration, existing idea, request declined.

• Future feature consideration: if it is determined the request should be considered for a possible feature, an Idea will be created on the Jira Product team board for the product team to manage moving forward. The Idea created on the Product board will be linked on the original request, and the original request can be closed.
• Existing idea: if it is determined the request fits within the scope of an existing Idea or Initiative, the new request will be linked to the existing ticket. Any additional context will be added to the description and/or as a comment on the existing Idea or Initiative, and the new request can be closed.
• Request declined: if the product team rejects a new request, the rationale for declining the request will be entered as a comment on the new request, and the ticket can be closed.

Once created, each new feature request added through Jira Service Desk will result in a notification in the #org-product-feature-requests Slack channel. If you have a high priority request, ping @pm in this Slack channel, using the :urgent: symbol and referencing the Jira Service Desk ticket.

In Slack, discuss individual topics within a single thread to help keep the channel cleaned up and easy to navigate. The product team will filter and manage incoming requests and loop in other team members, when necessary.

Communication on New Feature Requests

Initial discussions in regards to Jira Service Desk issues should take place in Jira Service Desk. Operations team members can comment on the ticket, when needed, to engage with Product. The product team will also comment on the ticket to ask any questions needed to further understand the request as it is being reviewed. The person who creates the new request should be engaged to help provide background information in order for Product to fully understand the request.

At times, discussions about an issue may happen outside of Jira Service Desk (e.g. Slack, email). When this happens, relevant details from the discussion should be captured as a comment on the original issue, so the history is complete and can be easily referenced later. This may include screenshotting, linking to Slack archives, or summarizing a discussion/email thread.

If a member of the operations team wants an update on an issue and aren’t getting one through Jira Service Desk, they should put a note in the #org-product-feature-requests Slack channel, with a link to the referenced request from Jira Service Desk. Any conversations in the Slack channel should be summarized as comments on the issue itself.

Workflow Status

We will use workflow statuses within Jira Service Desk to keep the engineering teams and operations teams informed with where we are on each particular issue. As progress is made on an issue, the status should be updated, as well.

Below is an outline of the various statuses and corresponding descriptions of how and when they should be used.

Closing Tickets

Once Product has fully reviewed the request and a determination has been made (future feature consideration, existing idea, request declined), it is the responsibility of the person who creates the issue to ensure the original ticket gets closed. Issues should be swept through on a weekly basis by the creator to ensure resolved issues are closed in a timely fashion.

To close a ticket, update the status to Issue is Closed. You will be required to select a Resolution in order to indicate why the ticket is being closed and should always leave an internal comment outlining specific details of the resolution.

Below are the resolution options available and a description of when to use each.

Note: Only one resolution can be selected and the issue will have to be reopened to change a resolution. If you reopen an issue, the Resolution will be cleared.

Tracking New Feature Requests

When a request has been reviewed and it has been determined it will be considered as a future feature, the product team will create a new ticket within the Jira Product board (or link to an existing one, if the request matches an idea that has already been captured). The new ticket created on the Product board will be linked to from the original request on the Jira Service Desk ticket as a point of reference and will be where we track progress moving forward. The Product team will manage the tickets on their board as they plan and prioritize future work for our teams. Within the Product board, tickets will be categorized as Ideas (items that are in the backlog to be reviewed and prioritized), a Pitch (an item that isn’t on the roadmap but we are working to plan), or Initiatives (items that are currently on our roadmap). As prioritization of requests occurs and work is added to the roadmap, these tickets will be converted from Ideas to Pitch to Initiatives. When a project gets removed from the roadmap, it will be converted into an Idea. The Idea/Pitch/Initiative status will reflect our best understanding of where a project sits in terms of its progress at any given time. For all Initiatives that currently live on the roadmap, the projected completion dates will also be reflected on the ticket. The Banno Roadmap will provide the most up-to-date public estimates of work to be completed.

Communication with Customers

If the new feature request is coming directly from a customer, ask questions to fully understand the request: gather context, understand the use case, have them explain how the feature will help them and their customers. When information has been gathered, offer to take the request forward to our product team to review and provide information on where and how they can stay up-to-date with the work we are completing. We cannot promise that a request will be completed, but can let them know it will be considered. Because of the amount of work we’re running through our teams and the prioritization and planning that takes place for all work our teams are completing, these cases should be closed once the request has been captured. Our teams internally can stay up-to-date with work in progress by following along in Jira and following monthly updates to the roadmap. Our customers are able to stay up-to-date with work in progress through the monthly statement, roadmap, and meetups.

Use our canned verbiage as a starting point when responding to customer enhancement requests.

Go-live blocker projects for an FI

Go-live project identification

Projects that are required for an FI to go-live with Banno generally are image, document and Custom projects assigned to Robin Vaughn’s team. These projects should be identified and called out at the kick off meeting. Robin has her process for providing the FI a quote and managing her Custom projects and timelines. She attends the kickoff meetings and will work to help understand the go-live projects the FI will require. The Operations Sync meeting will review the go-live blocker projects.

Working in Jira to setup the FI and go-live project

The following steps will accurately setup Jira allowing Product, Operations and dev teams to track go-live projects.

Search for your Customer FI in Jira by FI Name or number. If you cannot find the FI, you will need to create the “Customer FI” record by clicking the “Create” button at the top of the screen.

1. You are creating a new Customer FI record
2. Summary format = FI name + : + Company ID
3. Description = City and State and any distinguishing information
4. Click the “Create” button
5. If you have any additional details, enter them now in the newly created Customer FI record. Company ID, IC, JHA Core, FI Type, FI Assets, MAU, Estimated live dates.

Search for your Go-live project in the Product project. Most likely the initiative will not be found and it will need to be created by clicking the “Create” button at the top of the screen.

1. You are creating an Initiative in the Product project.
2. Enter the name of the project in the Summary textbox
3. Click the “Create” button
4. Open the newly created initiative and scroll down the “Linked Issues” section. Click the + button to add a new linked issue to the initiative.
5. Select “FI Blocked” in the dropdown
6. In the textbox, start typing the FI name. In the search results, you will select the Customer FI record that is blocked by this project. The Jira ID for Customer FIs start with “FI-”
7. Click the “Link” button. You have linked the Initiative to the Customer FI and designated it “FI Blocked”.