How do I get started?
Mercury is simple to use once you get down the basics. Let's walk through and make sure it is clear what every part of Mercury is for and what value it brings to your client-outsourcer relationship.
Mercury is the central truth in outsourced software development.
Create an account and add team members (optional)
While you are creating your team by clicking "create an account" on the login screen, you will have the option to add team members. Feel free to add clients, PMs, and Developers that will have access to the team and project you are creating. Don't worry, you can skip this and invite users later through your profile. You are also able to create more projects once you are signed into your account and add users to those separately.
The Overview dashboard
When you first get to your dashboard after logging in or creating an account, you will see 5 columns all corresponding to the milestones in an agile development cycle. This dashboard is client-facing and designed to let PMs & clients discuss and plan the sprints that will make up the development now and in the future. Developers do have the ability to see and comment on these cards as well. We will go over each column in depth below.
Messaging is the first place we find the ability of Mercury to keep the team on track and conversations in their place. There are 4 levels of communication that can happen on any project's dashboard.
Direct Messages - Any user is able to directly message any other user that is also on this project.
Per Item - Each item has a comment section to allow for granular detail on items in sprints.
Per Sprint - These conversations allow you and the client to collaborate and discuss issues with particular sprints.
Per Dashboard - Found beside the name of the dashboard (on the right), you can also click the messaging icon there and have general discussions, such as billing or other non-development related conversations between you, your team, and the clients.
This is the backlog for the software. It is named Planned Items to be straightforward to understand for clients. You can easily add new items and click to expand them into their detailed view which allows you to set the user story and hours required for each item. If you or your client would like to add a new sprint, you need to add one item minimum.
Clients abilities aren't curtailed in this column. They are able to move items within sprints, create items, sprints, and anything else. They, along with the full team, can do these along with moving sprints from this Planned Item stage to the "Next Up" stage where client abilities will change and the sprints will be confirmed and started.
After clients &/or team members have clicked "start development" in the Next Up column, the items are confirmed and automatically moved into "technical staging". This stage is also where the development board's cards are auto-created on the Development dashboard (more on the Development Dashboard here). While items are being prepared and all the required documents, files, and requirements are hashed out on the Development board, developer or PM users will be able to move items into the next phase, "in Development" by clicking the button on the development dashboard.
The main reason for this column is to give development to have technical discussions with the PM or other client-facing team, out of the view of the client. This cuts down on technical overload, but through the PM and Overview dashboard, keeps all the sprint's expectations equal across the whole organization.
Clients are NOT able to move items or sprints in this column or any others. This keeps clients from accidentally changing an item or moving items out of sprints after the sprint has begun. By clicking "start development" in the Next Up column, our experience showed this led to an ownership and agreement to the items in that sprint. Focusing on sprint-by-sprint mechanics instead of large specification documents and months and development led to much better clarity for the full team, client included.
Once development has moved items into the development boards "in Development" column (more on the development dashboard here), the corresponding cards on the Overview dashboard will also move from Technical staging to In Development.
Doing this gives more movement which has been found to help keep clients encouraged by seeing progress, but this specific process also mitigates any technical details being shown to the client which leads to technical overload and confusion, ultimately hurting trust and less software being developed.
Clients will still not be able to move items or sprints when in this column, but commenting and general updates can still be given in the general (by the dashboard name), by the sprint (at the top of each sprint) or by item (in each item's detail).
Once development is done with the sprint to their satisfaction, they will click "send to client for approval" on the development dashboard (more here). That is when the sprint is automatically moved into Needs Approval from in Development. This is where the client and PM will work through testing and checking off any acceptance criteria in order to approve the sprint.
If a sprint isn't complete and fails any of the requirements, the client or PM can select "Reject" and the sprint will be sent (on this, Overview, dashboard as well as Development dashboard) back to the in Development column.
This gives clients the ability to turn the page on a sprint easily and transparently as well as straightforward evidence of completion so the development cycle can continue and the progress can happen as quickly as possible.
Clients are given the option to finish the sprint once all the items are to their satisfaction (or a PM can do this). By clicking Approve & Close, the sprint is moved to sit in the History dashboard.
The final resting place for sprints is the History dashboard. Located on the bottom of the left menu, clients and team members can see a time-stamped collection of their history of sprints on the project.
These come in handy when you are developing for a second operating system or disputes come up. The itemized history stands as a lasting reminder of what has been previously done.
No user (including Team admin) can change items once they are in this dashboard. This is meant to proetct its ability to be a complete and unaltered system of record for all development on the project. This protects in the case of claims the client or developers didn't get what was discussed. All items, their details, and their comments are kept to keep everyone's memory exactly accurate and eliminate those few instances when clients or developers dispute work as being done previously.
Mercury is the central truth in outsourcing your software project. Through painstaking efforts over years, Mercury turned into an invaluable tool for planning, leading, developing, and communication between clients and outsourcing freelancers and firms.