As a VP of Engineering, I work with more than 30 software engineering teams. Over time, I developed a heuristic to help me identify velocity issues quickly.
The four questions:
Is there high unplanned work or work that's not part of the plan?
Teams have high unplanned work when there is frequent urgent work or failure demand (quality problems). These teams can't focus on the important work.
Is the team cycle time way higher than the active time?
The cycle time is the time it takes to complete a work item from start to finish, while the active time is the actual amount of person-hours spent on the work item.
Cycle time can be much higher than the active when teams have too much work-in-progress or priorities changes too often. The team can't complete work sooner due to simultaneously juggling too many work items.
Is the median active time is too high?
When the active time is high, it usually means that the team has a slow feedback loop.
The team might be working on items that are too big in scope, causing that they spend many hours on a work item and that design and code reviews take a long time. It might also be a symptom of a brittle CICD pipeline or a lack of automated tests.
Did the team deliver valuable projects in the last six months?
Some team has none of the issues described above but still fail to deliver value.
In those cases, I usually see that the team is snacking, meaning that they do a lot of small, quick, but low-value work. Additionally, it might mean that the team focuses too much on the technical roadmap vs. the business needs.
Beyond this heuristic
These questions do not attempt to build a complete model for evaluating team velocity but work as a quick heuristic to identify what kind of velocity issues a team might have.
Follow me on Twitter for more articles on leading software engineering teams. I publish twice a week.