I’ve worked with a large number of development teams over the past few years, all using some flavor of Agile to build backlogs and manage their work. I’ve witnessed very few teams who do this well. Considering that Agile is supposed to be a team-driven, team-focused process, failure to effectively do the basics of Agile at the team level means that the desired benefits of Agile won’t be achieved at the organizational level. Here are some of the most common problems I’ve encountered.

Failure to Groom and Plan

Teams are stretched too thin to perform the regular grooming and sprint planning activities needed to maintain a consistent velocity. At the beginning of a sprint, they pick up features and “groom as they go,” which means the conversations that are supposed to happen with stakeholders aren’t happening. Acceptance criteria are often missing or weak.

Using Features as Buckets for Assigning Development Time

Since developers are usually required to account for all their working time against the backlog, there is a motivation to create and hold open a catch-all feature for developer time. This feature will stay open for a long time and may have multiple stories against it which don’t have meaningful descriptions or acceptance criteria. These generic features make it very difficult for people inside or outside the team to really see what the team velocity or committed scope is.

Making Epics or Features Too Small

A few teams I’ve worked with tend to have one story per feature. The hierarchy of an Agile backlog is pretty flexible, so they could just skip the feature level if that doesn’t make sense for the team. Or, they need to make features bigger. A one-to-one relationship of epic to feature or feature to story just makes the backlog bigger and harder to maintain with extra work items that provide no value.

Everything is a Technical Story

This can happen when the development team is working in isolation from business stakeholders. They write the backlog in IT-speak. User stories, features, and epics don’t describe business capabilities; they’re a laundry list of IT tasks. It’s almost impossible for a business stakeholder to make sense of the backlog or to figure out how to test any of it. This is symptomatic of a “you told us what you want, now go away and let us build it” mentality that undermines the heart of Agile.

Skipping the Scrum

This often happens when demands from outside the team cut too much time out of the daily schedule. Something has to give, and development has to proceed, so the daily stand-up meeting is sacrificed. Team communication, cohesion, and mutual accountability suffer as a result.

How can organizations who really want to get better at Agile counter these bad practices? For Agile to succeed, it isn’t enough to send all your developers to a 3-day Agile training and assign a scrum master. Teams must be given enough autonomy to do the daily, weekly, and bi-weekly processes that keep Agile working. They should also be supported with collaborative coaching that helps them to identify opportunities for improvement without judgement or punishment for the mistakes that they will inevitably make along the way. Otherwise, organizations end up hiring people to provide layers of oversight and management of the Agile teams, which really just ends up being the same old thing that Agile was supposed to move us away from.