.png?height=120&name=Variant=Default%20(1).png)
How do I interpret the visualizations, and what kind of action can I take?
⚠️ Note: Getting the full benefits of Work Log depends on reliably linking Pull Requests with Issues. This is something you should discuss and agree to do as a team.
Working alone
People tend to gravitate to working on their own thing because it's easy and doesn't involve coordinating with others. However, great teams are built upon collaboration and sharing knowledge.
In Work Log, look for Stories, Tasks or Epics where you can only see one contributor. Could they use a hand?
Being able to work on the same feature sets the bar higher for planning, because you can't figure things out as you go. This is generally a good thing: better planning reduces wasteful rework, but it can feel painful at first.
Siloed work
Another form of siloing is when some people always gravitate to working together on the same features or when someone is stuck only fixing bugs or reviewing code.
In Work Log, look for patterns in which individual contributors are only working on one kind of thing. In the example below, the bottom contributor is mainly reviewing code instead of a balanced mix of commits, pull requests, and reviews.
Days without progress
We're encouraged to stop starting and start finishing, but something urgent always comes up. Even short disruptions can impair flow, and context switching is expensive.
In Work Log, look for Stories, Tasks, or Epics where contributions like Commits and Pull Requests are few and far between. Is the team getting interrupted or working on too many things at the same time?
It's also possible the team has a habit of creating larger commits and Pull Requests. Delivering in small batches makes it easier to get reviews, so it can be helpful to practice splitting the work.
Too much reactive work
Everyone is happy when teams are working on the roadmap. However, it's important to stay on top of housekeeping or progress can grind to a halt.
In Work Log, look for disproportionate contributions in the Bugs and Uncategorized lanes. Are there issues like technical debt that warrant a conscious investment in refactoring or an architecture review?
