One thing we are proud of at MantisHub is the versatility of the product. We have customers using our service for general task management, software development as well as project management. Some use it internally within the team and some use it to streamline collaboration with their clients. The simplicity and flexibility of MantisHub, means you can engineer it to address a wide variety of needs.
MantisHub is used for Project Management by about 70% of MantisHub users and we have a number of handy features designed to help out our project managers including the Changelog and Roadmap features.
Highly rated by our customers, both these features come into effect once you decide to split your projects into versions (or releases or iterations or milestones… whatever terminology fits in your use-case). For software projects it’s common place to both Agile and waterfall frameworks, that you would manage your software development and updates in terms of versions, releases or sprints. When doing this, two helpful things to know:
1. What are the changes in a specific version?
2. What is the planned work for a specific version and how are we progressing towards that goal?
The Changelog helps you answer the 1st question by allowing you to set a ‘fixed in version’ field when issues are resolved. As you go through and resolve issues with MantisHub and set the ‘fixed in version’ field. The Changelog then groups resolved issues by version they were fixed in. This information is the pre-curser to your release notes for software or communication to partner teams within the company or clients externally. It’s also handy for reporting up the line on team and project goals met.
The Roadmap answers the 2nd questions allowing you to set a vision and your goals for future versions/releases by setting the ‘target version’ field. You can use this to let customers, partner teams, and team members know what you have coming down the track as well as helping you keep track of development progress and project milestones etc.
So here are our 10 tips for making the most of your Changelog and Roadmap
1. Make use of your version fields
There are some fields you should take note of when setting up your versions that can add value to your CL & RM.:
- Consider adding a description to version to be shown on CL/RM.
- The release date you have set in the version will impact the CL/RM as it will display versions with the most recent release date at the top.
- Version names on CL/RM are hyperlinked, hence, it is easy to link a project or a specific version from your blog, website, wiki, etc. Access may require user to sign-in if anonymous access is not enabled.
2. Keep your version status up to date
To make your CL/RM relevant you should keep you version status up to date. Once a version is released, make sure that it is marked as such to have it removed from the Roadmap. Once a version is too old and not needed on the Changelog page, then mark it as obsolete.
3. Take advantage of ‘View Issues’ button and group actions
Don’t underestimate the use of the ‘View Issues’ button in your RM & CL information to have the issues opened in View Issues page. This handy shortcut will allow you to take further action with all relevant issues such as printing or exporting but we find the most useful way to take advantage of this is using group actions.
For example you have a list of un-assigned issues in your Roadmap for version 2.0, bring them up by clicking ‘View Issues’ out of your Roadmap view, select a sub-set or even all the issues listed and assign it to your victim… umm… developer. Check out Tip 9 for another example use.
4. Use issue relationships to save you time
Make use of the relationships feature in MantisHub to define dependancies in your issues. This is useful for many reasons (have a read of this article). Issues on the RM/CL are grouped together under parent issue, providing an easy way to group related issues.
5. When resolving issues for maintenance & feature releases
If you have a fix to an issue that was applied to previous release maintenance branch as well as a future feature release, you can clone the issue and mark the clone as fixed on the second branch. This way it shows up in the Changelog for both releases. Alternatively you can open a related issue to port the fix to a different branch and marked as fixed in the appropriate target branch.
6. Meaningful Issue titles
Keep in mind that issue titles appear in CL/RM and will be presented to a CL/RM audience. When creating issues, set guidelines for your issue titles. Make sure you don’t use jargon your audience won’t understand and make titles meaningful, showing the value added by delivering the issue, rather than how it was done. You can also go back and edit issue titles for those that don’t meet your guidelines.
7. Meaningful Categories
Category information is also displayed in your CL/RM so similar to tip 6, name your categories in-line with with how you present your feature groupings to your customers. This way they can easily locate what issues they care about. For example, categories can include administration, api, localization, integrations, etc.
8. Don’t feel shy to add issues to RM even if they have already been resolved
If an issue wasn’t planned for a release, until after it was resolved, go ahead and still set the ‘target version‘ so that it shows up in the roadmap. Your customers will still want to know it is coming in the upcoming release.
9. Factor shipping into your workflow.
CL/RM are all about project management and delivering value to your users. Hence, it is important that your teams workflow also reflect that. For example, we often use the “Resolved” status to reflect an issue that the team fixed, and use “Closed” status to reflect that it was published in an official release or deployed to production.
Hence, a common part of the workflow is that only after version X is released/deployed, are issues with ‘fixed-in version’ X closed. See tip 3 for the easy way to do this using group actions.
10. Create future versions to enable planning
Often the team triage incoming issues and target them for appropriate releases. For example, an issue may be needed as a hot fix, vs. next minor release vs. next major release. Hence, it is important to have such versions available for your team to start targeting issues for as they are being triaged.
Depending on what you are using MantisHub to manage, there are probably more ways to leverage Changelog and Roadmap for your usage, or even hide them completely, if you are going for minimal task management with no equivalent of deployments / releases.
Share with us on twitter @mantishub your own tips and tricks for using MantisHub and boosting your team’s productivity.