Cross-dysfunctional Teams and the Story Point Fight

Claudio Gennari

Agile developers know how to estimate story points for customer features. And while transferring this knowledge over to the project team can take a few sprints, it is speedily adopted and velocity becomes a focal point of the sprint planning games. But, if the all the project participants aren’t officially on the team, a growing gap will appear between where the team wants the project to go and where the other participants thinks it should go. Story points quickly become a source of frustration and conflict instead of helping to gel the project team.

In my case, the core project team is 100% committed, but there are a few external folks from support and QA who are involved in many other projects. From their viewpoint, our project is just another task on their ever-growing checklist of product support. They don’t care about new user features – they want the bugs fixed. Because the project team only gives points to new features, the support colleagues feel left out and forgotten. Their job is seemingly made harder by our “overlooking” bug fixing.

Let’s be clear – we do a lot of bug fixing – actually, way too much! As we have no automated tests, we get the disastrous effect that fixing one bug causes three others. Roughly 50% of our sprint stories are bug fixes.

A cross-dysfunctional team like we have will never be able to come together and agree on the importance of regularly delivering customer value and unit-testing. Their loyalties lie with different departments and organizations. To get a truly committed, cross-functional team everybody needs to pull together in the same direction, to have a common understanding of the teams goals and feel 100% empowered in making the decisions to make their vision reality.

As for how we can increase our velocity, the answer is quite clear: start writing tests. At the very minimum, stop making anti-fixes!