Requesting Work From FED
FED's Purposes#
- Empower teams to develop Hub applications
- Perform Hub development for teams unable to do so themselves
If you’d like to request any type of front end work from our team (specifically web work, such as Hub apps, HTML, CSS, and JavaScript), here are the steps:
important
Note that requests to FEDs can be made, but until all the info is provided we will not start development
Add a new work item through Zendesk by emailing fedrequests@iqmetrix.com with this template
- a feature or bug specifically for the front end work
- will have severity and a proposed deadline
- will include some details about the request and link back to any larger work item on your own Aha! project or ADO work item (ie. include a link back to your original epic, work item, etc.)
- bugs must have full reproduction information, including screenshots if necessary. Remember - we may not have context on your app!
- only ONE bug or work item per issue. If you log multiple items, only the FIRST issue will be looked at. Subsequent bugs/features will be ignored.
- bugs must have clear, step by step reproduction steps (ideally with screenshots). Please do not assume our developers will have context on your app.
Once we receive the work item, it will be validated by a designer/FED, and estimated by our team, within 1 week. We will:
- ask any clarifying questions and then accept the request
- propose a start date, story points, and delivery date
- place the request into Aha!/ADO (see below)
- any work item which requires a UI change - even a wording change - must include a designer's name. Bug fixes, such as UI changes which do not meet acceptance criteria or mocks, do not require a designer's name.
When we begin work, we will break down the Work Item further if necessary, and move those item(s) into a sprint iteration. We will update the work item as we work on it (see below)
info
Please provide us with contact information (group email or individual) that we can include in the ticket so you can be updated on the progress. As the owner of the app you are responsible for deployments furthar than int environment.
tip
We strongly encourage your team to be involved in the front end work. This can include doing the work yourself with our mentoring or assigning a developer to work alongside our team, and understand how it is built.
Feature Requests#
We prioritize new feature and app requests on a first come first served basis.
Have features already in Aha! that require front end work?#
Break them down into front end features if they haven’t already been, and add them to our Backlog for acceptance! Read the first part of this document for the process.
We use Azure DevOps (ADO) to break down our work. How does that work?#
We may create an item on our Aha! backlog for road-mapping. We will add a link in the description back to your ADO front end work item. You can either move those ADO work items into our ADO backlog, or we can create separate work items for sprint planning.
Do we give you our Aha! features or are they duplicated?#
If you require the Aha! feature to also exist on your roadmap, then they will be duplicated on our backlog. You will be responsible for keeping track of that item on our Aha! board.
Bug Reports#
How do I request bug fixes to an app that affects our team?#
Create an issue on our Azure DevOps backlog as a New Work Item: https://dev.azure.com/iqmetrix/Hub/_workitems/recentlyupdated/
Enter the title of the Bug, steps to reproduce the bugs (Repro Steps), leave it Unassigned, and a Severity. We will validate and accept the bug, provide an estimate in Story Points and when we can get to it, and assign it to an iteration.
Alternatively, you can create a work item just like the steps above, via ZenDesk.
For bugs we prioritize using the following priority matrix
| All Users Affected | Many Users Affected | Few Users Affected | |
|---|---|---|---|
| Important Functionality Unavailable | Priority 1 | Priority 1 | Priority 2 |
| Workaround Available | Priority 1 | Priority 2 | Priority 3 |
| Non-blocking or Obvious Workaround | Priority 3 | Priority 3 | Priority 4 |
Priority Definitions#
- Added to the current sprint and started immediately. Even at the expense of completing sprint goals. Likely involves the effort of multiple team members.
- Added to the current sprint. Must be completed prior to other sprint items but may be delayed by other bugs.
- Added to the current sprint at the discretion of FED team. Otherwise prioritized to the top of the backlog.
- Added to the backlog and prioritized at the discretion of the FED team.
Incoming requests#
- When other teams request work from our team, they will follow the ZenDesk process
- Summarily, we:
- acknowledge the request and submit ticket as Open
- validate, ask clarifying questions, and accept or reject the ticket
- if accepted: create a work item (user story or bug) in Hub Azure DevOps. Add a link to the original ZenDesk ticket and add the requesting team's Azure DevOps issue, if applicable. Move the work item to the
Backlog/Triageiteration. If the ticket is an SPT&A or Injection, add the SPT&A/Injection tag to the item. Add a link to the work item in the original ZenDesk ticket, and close the ZenDesk ticket. Tag the requester in the Azure DevOps issue so they receive email updates. - prioritize the work item
- groom and estimate the work item (see below)
- once the item is complete, we will close the work item. The original requester will automatically receive email updates. If needed, all formal discussions will be conducted within the work item in Azure DevOps.
- If an external team is requesting work on a new app, we will make sure designs are complete and validated by a FED member. A clarification meeting will be held with a member of the external team and a designer. Once the app request is accepted, the FED team will create, groom, and estimate the front end user stories alongside the external team. Then sprint planning and work will begin.
General questions#
Do you want to see how busy we are, to get an idea of when you can do your work?#
Look at our Aha! Backlog and Roadmap for a general idea of how much work we have.
What if our team would rather do the work ourselves?#
EVEN BETTER! Our new React stack is designed for easy on-boarding, with a boilerplate, a design system, plenty of documentation and examples. All we ask is you open a simple, corresponding ticket in Azure DevOps so we can track external teams’ work and make sure we have resources allocated to do code reviews.
Will you do the work faster than if we ask our devs to do the front end work?#
If we do your work, we will need to find an iteration for our devs to pick up the work.
If you do the work yourself, which is strongly encouraged, there will be a ramp-up period to learn the stack, which we will help you with. However, you have much more control over the development timelines – plus any minor bug fixes in the future.
How do I submit bugs/feature requests for frontend-packages?#
We own the front end packages! Use the GitHub issue tracker and select Bug report or Feature Request templates
What about RQ/Mobile/Mobile Hybrid?#
Initially, we will only handle web work.
FEDs do the work… so do you own it?#
Nope! Your team owns your product(s) from front to back. You will be responsible for monitoring the app and ensuring we are building the right things. We will support your team but you will ultimately own the product and the release process.
What work do the FEDs own?#
The FED team will own the infrastructure around building web apps, including the Hub Shell, but primarily the frontend-packages on Git. The Design System – such as the shared components, style guide and styled tokens – will be co-owned by the FEDs and Design Team.
What happens after I send out the email template to fedrequests@iqmetrix.com?#
We will contact you within 48 hours with clarifying questions so we can estimate and provide an estimated start date, end date, and story points. The estimates will be provided within a week.
If our team will do our own work with code reviews from the FED, do we have to wait for approval before we can merge in PRs?#
No! It is your code and your team's project.