Jira, arguably, has become synonymous with project management, as it aligns perfectly with the PM's objectives. It provides an easy way to track tasks, activities, and teams' progress and helps deliver on time if used correctly.
However, project management is a cross-disciplinary practice, which requires different views of things to be proficient. And this is where the whole Atlassian ecosystem comes to shine with the synergistic effect of its products.
To get a deeper understanding of the processes, it might be useful to dig into the development processes using Bitbucket. The engineering metrics that you can get from it can help you make goals and objectives clearer, find bottlenecks, and spot process improvements.
But in the core of project management is collaboration and communication with stakeholders, leadership, teams, and clients. Here Confluence comes handy as it allows team collaboration, planning, reporting with easy access for everyone. It allows us to address challenges at work effectively by using the combination of the native macros with third-party solutions.
In this article, we will show you how to aggregate data from Jira and Bitbucket and build a fully-fledged dashboard for project management in Confluence, using the Table Filter and Charts for Confluence and Awesome Graphs for Bitbucket apps by StiltSoft (the company I work for).
The Velocity chart visualizes the amount of value delivered by the team per sprint. This information is essential for effective sprint planning and delivery time prediction. You can calculate the teams’ velocity and define the amount of work a team can tackle during a single sprint using historical data.
The Burndown chart serves as a graphical representation of the work completed versus the total amount of work planned for the sprint.
In this chart, the vertical axis shows the outstanding work, with the horizontal axis serving as a timeline. Using it, you can see the teams' progression against the work planned and keep the team running on schedule.
The Gantt chart helps you get a snapshot of the whole project or its stages. It serves as a timeline that illustrates how the project will run. You can see individual tasks and their duration and group them by different criteria: sprint, type, component, assignee, and more. Besides, you can expand the given chart with a percentage values column to display the completion ratio.
The Pull Request Gantt chart helps you identify the tendencies and patterns in pull request resolution time for each user. It can help you predict using historical Git data if your team can finish the tasks by the end of the sprint.
To make realistic predictions, you need to look at the average age of PRs created by the author. Suppose a developer is junior or new to a particular repository or project. In that case, they tend to make more mistakes or are subjected to more thorough reviews and testing, which potentially delays their PRs, which you need to consider in your planning.
This chart displays the level of activity of the developers measured by the number of commits. You can see which developer worked on a particular project and identify the top contributors in your teams. It might also be useful to find the most active repositories in the instance, for example, when you plan some process improvements and want to know which teams to target first.
Using the Lines of Code chart, you can visualize and calculate the amount of work done in the projects and see the developers' activity in terms of lines of code added and deleted.
Note that it's not the best idea to measure developers' impact by the number of lines of code as often best-designed products are written with the fewest lines of code. These metrics should help you get a deeper understanding of the processes, not serve as a base for somebody’s career decisions.
To complete the picture, you can use the following chart showing the developers' pull request activity, i.e., the number of open, merged, and declined pull requests on the project level basis.
This chart allows you to visualize the statistics about developers in your teams across multiple or all of the repositories, grouping the pull requests by their state.
Please note that there are surely dozens of other ways to do the stuff described in the article, and we show just how we do it. Hopefully, the provided graphs and charts will help you get the reporting insights out of the data from Jira and Bitbucket and will give you more visibility into the processes.
Our support documentation provides you with instructions on how to build the charts based on data from Bitbucket and the ones made using the Jira Issues macro.
Dmitry Trofimov
0 comments