Be Aware of the Agile Anti-Patterns Baked in Your Tool of Choice

‘People and interactions over processes and tools,’ the Agile manifesto reads.

When you pick a tool, you should be very careful. It comes with misconceptions and interpretations of what it means to do Scrum or Agile, that may set you back.

Let me show you what happens for a few different tools like Jira, Azure DevOps and Rally.

Sprints in JIRA Suck

Let’s say you’re using Jira and you’re trying to create a board for your Sprints, and you try to change the Sprint afterward:

BOOM! You’re already confronted with two mistakes. The choice between Scrum and Kanban is the first mistake. The second mistake is suggesting that Sprints have a scope that should not change. If your scope doesn’t change, you shouldn’t use Sprints. The Sprint Goal doesn’t change, the Sprint should change, as that’s the nature of complex work.

Okay, so now let’s say you’re using Azure Devops instead, with the Agile process template, what kind of problems do you bump into?

Azure DevOps: The Default Hierarchical Structure Doesn’t Make Sense

When you’re talking about Epics, you’re already talking about your portfolio backlog. This doesn’t make any sense. You don’t need a portfolio backlog to have an epic, nor do you have to break down Epics into Features.

There’s also a clear hierarchy from Epic → Feature → User Story → Task

I want to stress this is all configurable, and you can also choose a different template, but you have to be aware the default templates suck. A User Story can be an Epic. A User Story can result in one or more features. It’s precisely the other way around, as the default template suggests.

I understand why many companies work this way. They’re not using User Stories, but User Fairytales. They abuse User Stories to describe Features and Epics they’ve already decided to build. They’re not real stories about the user.

But because many companies work that way, doesn’t mean it’s the right or best way of working. Now let’s take a look at what happens when you use Rally.

If you use Rally, then you suffer from the same kind of problems:

Themes (Investment Categories) → Initiatives → Features → User Stories

These strange hierarchies probably have their roots in SAFe kind of thinking, which has the following hierarchy:

Epic → Capability → Feature → Story.

So, in short, be careful when you choose a tool, and don’t let the default way of working dictate how you should work. Breaking down work is supposed to be fluid, and all these tools try to make it rigid, like there is one way you should do it.

A User Story can be an Epic.

A User Story is not the same as a Feature. You don’t break down a Feature in User Stories. You can use a User Story to guide the development of one or more Features. That’s because features should be rooted in your users' real-world stories.

Features should be rooted in User Stories, not the other way around. We’re building things to change their situation and grant them progress. That’s what the User Story is supposed to help enable. User Stories allow us to be anchored in their reality instead of the solution reality of what we’re trying to build.

When describing Features with User Stories, you’re doing User Fairytales. Just skip the nonsense because you don’t need User Stories at all to describe something you’ve already decided to build that’s not rooted in the reality of your users.

Use these tools to enable your way of working, don’t let them dictate your way of working, as their sensible defaults are not all that sensible.