- Published on
Stop wasting standup time as a manager
- Authors
- Name
- Stuart Dotson
One of the most common ingredients of the software engineering standup meeting is discussing what each person did and what they need to do. This common ingredient is also the biggest waste of time because as software engineers, nearly all our work leaves a digital footprint in Jira and GitHub.
Why are managers asking software engineers to recite their GitHub and Jira activity in person? Wouldn't that time be better spent discussing things that don't exist in those platforms, like blockers, unexpected challenges, and opportunities for collaboration?
Surely, as engineers and managers, we can do better.
I'll go over some of the significant downsides to relying upon a Jira Sprint Board for standup meetings before presenting the solution to this important problem.
Downsides to the Jira Sprint Board
Jira has a Sprint Board view where you can see the individual tickets defined for a given sprint, their Jira status, and their assignee.
The most glaring omission in this view is that there isn't an easy way to quickly correlate GitHub pull request data, which is one of the main outputs of engineering work, with those tickets.
You could ask individual software engineers during standup for the status of each Jira ticket, including GitHub activity. This is an extremely common and also very annoying approach. Software engineering work leaves a trail on GitHub in the form of GitHub pull requests and commits. It is inefficient to ask engineers to verbally recite information that exists in a digital platform. In addition, it uses up precious time that could be spent discussing blockers or other more qualitative information that is more likely to exist outside of a digital platform, perhaps the human brain.
Let's say you agree that it's a waste of time to force your direct reports to recite their Jira and GitHub data to you. You could take on that additional work as a manager.
You could install the GitHub for Jira app, which will link GitHub pull requests and commits to individual Jira tickets if you follow specific naming conventions. Even then, you'd still have to click through individual tickets to see the associated GitHub work. If you want slightly more detailed information about the GitHub work, like how long a pull request has been open, has it been reviewed, that sort of thing, you'll have to click through to the individual pull requests as well.
That's X Jira tickets x Y GitHub requests worth of clicking. You'll probably either have at least that many browser tabs open or you're writing down notes.
The solution: BeyondDone
The BeyondDone app recently launched a new Team page, which presents a view of all the Jira tickets in a given sprint, organized by Epic. For every Jira ticket, there are the associated pull requests and the state of each pull request, including if it's been reviewed and how long it has been open. All this is filterable by epic, project key, assignee, and Jira ticket status category (to do, in progress, done).
This page shows you everything you care about in the sprint. Details like individual pull requests or reviews are collapsible, allowing you to choose the level of granularity you want to see. Imagine having this report open during standup so your team can focus on the important stuff.
But why take my word for it? Try it out for your next standup meeting by signing up for a BeyondDone account. It has a 30-day free trial, and no payment details are required.
At the cost of setting up the report manually every single time, you can also use our public Team Sprint Report Generator. No account creation is required for that one.