Transparency is our everything, or New Jira reports to help the project manager

Hi, Megamind!

Today our colleague Illarion Ostapov will share a small life hack for project managers. Hopefully, someone described the useful and make everyday work a little more productive.
')
I am sure that this happens to you too: an interesting project comes, filled with non-trivial logic, integration with different closed systems and the client's expectations, after six months, start using it in production.

And you and your colleagues (and maybe not even you, but someone before you, as was the case in my case), relying on a wealth of experience, are sketching a plan. The plan looks wonderful, and according to it all features are exactly on time, and the burn rate is within customer expectations. In a word, not a project, but a fairy tale, but kick-off passes - and the fairy tale begins to smoothly turn into life.

You also know perfectly well what happens next: errors in the assessment of tasks, changes in requirements, unforeseen departures of team members, unrecorded technical tasks, the need for refactoring, an increase in communication time due to team growth — you can list them for a long time. What is the saddest thing to avoid these moments is extremely and extremely difficult.

I admit, I did not want to lose the reins of the project and the expectations of the client. The search for his path began with status tracking through the msproject-plan with the further transfer of spent and remaining hours into a monstrous table, followed by a no less cumbersome letter. Here is an example of such a message after one of the sprints, when the gap is already evident:



It was interesting to watch such reports to the client, but for me they became a living hell, because, as a rule, the preparation went on for a day. Given that the real scope of work and the initial plan with each sprint less and less resemble each other, the method was not at all effective.

As soon as I despair, colleagues came to the rescue, telling us that wonderful reports appeared in Jira Agile - Release Burndown and Epic Burndown. They allow not only to assess the current situation in terms of release and epics, but after three sprints to predict the number of remaining iterations based on the average performance. They look great, but there is a nuance: JIRA should be in perfect order, which means you should follow the rules:

• All issues should be tied to Epic and fix versions.
• The report can not operate on the sub-task estimeytah, it means that if you beat the user of the story on the sub-task, it is necessary to put down the estimate for each, and the total total estimate for the story. In this case, uncheck the include subtasks checkbox in the Time tracking section of the ticket settings and do not forget to update the estimate for the story when updating the estimate of sub-tasks.
• During the completion of the sprint, transfer all implemented and verified QA tickets to 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 spoil the statistics.
• And, of course, daily carefully record the time spent and update the estimate. 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 has forgotten to pledge time, or who is the main Stakhanovist in the team :)

By doing these simple daily procedures, at any time you can get a picture of what is happening in the project both in the short and long term. Having added this picture with small comments, you can make an excellent report in just 30 minutes. Here is how it looked at us:



Enjoy your projects!