What are the different roles in Mercury?
The hierarchy of membership to a team is as follows:
Team - freelancer or firm doing technical work with clients
Team Admin - adds projects & controls the team including roles
Project Manger - team member that works directly with the client & dev.
Developer - team member that does the technical (non-client facing) job daily
Client - getting software made, the non-technical person & most limited on Mercury
1. Team admin
This team member is the freelancer or leader in the firm. The team admin can create projects, see all dashboards, add and edit items anywhere on any project on the team, add team members, and generally be in charge of the Team they are the admin of on Mercury.
2. Project Manager
The Project Manger or PM are the go-between with the client. This type of team member talks directly with the client to get things set up and keep planning for future sprints. They also translate technical jargon (done on the Development dashboard) into client-facing conversations to get answers, but not overwhelm the clients.
Developers are the ones doing the technical work that the client isn't in direct contact with. This type of team member is designed to allow them to leave client discussions to others, but still have insight and give input on sprints an items (in and out of the view of clients depending on the technical nature of the item or sprint in question).
The client is the team member getting the software developed. This non-techncial user is allowed to manipulate items and sprints in only the very earliest of stages. This is also the user (along with PM) that can click "start development" to kick off a sprint in the "Next Up" column and "Reject" or "Approve & Close" on the "Needs Approval" sprints awaiting approval. They can comment on any item or sprint on the Overview dashboard, but they aren't allowed to move sprints or items beyond the clicking of the "Start Development" button in "Next Up".
Automation is integral to the Mercury Platform. Our system clones cards (and comments) only when items have been finalized leading to development only being handed finished and approved sprints. Having all of these cloned into a Development backlog gives them a couple milestones (columns) to prepare for launch of development. Items on the client-facing Overview dashboard will then move through the steps as they move on the Development dashboard until they require action by the client (or PM) to approve the sprint and move it to history.
The best way to learn this is to use it. Feel free to use it with one client and see how it works while in your development cycle, it is free until you add a second project. Sign Up to Try it Yourself.