Transparency is Our Everything, or New Jira Reports to Help Project Manager
Today, our colleague Illarion Ostapov will share a small life hack for project managers. We hope that the foregoing will be useful to someone and will make workdays a little more productive.
I’m sure it happens to you too: an interesting project comes along, filled with non-trivial logic, integrations with various closed systems and client expectations after six months to start using it in production.
And you and your colleagues (or maybe not even you, but someone before you, as was the case in my case), drawing on rich experience, outline the plan. The plan looks wonderful, and according to it all the features are exactly on time, and the burn rate is within client expectations. In a word, not a project, but a fairy tale, but kick-off takes place - and the fairy tale begins to smoothly turn into life.
What happens next, you also know very well: errors in evaluating tasks, changing requirements, unforeseen departures of team members, unaccounted technical tasks, the need for refactoring, increasing the time for communication due to the growth of the team - you can list for a long time. What is most sad - to avoid these moments is extremely and extremely difficult.
I admit, I did not want to lose the reins of project management and client expectations. The search for your path began with tracking the status through the msproject plan with the further transfer of the spent and remaining hours to the monster-like table, accompanied by no less cumbersome writing. Here is an example of such a message after one of the sprints, when the gap has already been outlined:
It was interesting to watch such reports for the client, but for me they became a hell, because it usually took a day to prepare. Considering that the real front of work and the initial plan with each sprint were less and less alike, the method became completely ineffective.
As soon as I despaired, my colleagues came to the rescue, prompting that wonderful reports appeared in Jira Agile - Release Burndown and Epic Burndown. They allow not only to evaluate the current situation in terms of release and epics, but also after three sprints to predict the number of remaining iterations based on average performance. They look great, but there is a nuance: JIRA must be in perfect order, which means that the rules should be followed:
- All issues should be tied to Epic and fix versions.
- The report cannot operate with sub-tasok estimates, so if you beat the user story on sub-tasks, you need to put both the estimate for each and the total estimate for the story. At the same time, uncheck the include subtasks in the Time tracking section of the ticket settings and do not forget to update the estimate for the story when updating the sub-tasok estimate.
- At the end of the sprint, translate all implemented and verified QA tickets in the closed status. If something hangs in resolved, the time spent on these tickets will not be written off in the report of the current sprint and, accordingly, will ruin the statistics.
- And, of course, daily carefully record the time spent and update the estimates. To make the picture transparent, I recommend installing the Tempo Timesheets plugin (thanks to Igor Maslennikov for the tip). So you can always clearly see who forgot to save time, or who is the main Stakhanovite in the team :)
By doing these simple daily procedures, at any time you can get a picture of what is happening in the project in the short and long term. Complementing this picture with small comments, you can make an excellent report in just 30 minutes. This is how it looked with us:
Enjoy your projects!