To begin this post, I want to say that I am a fan of agile. I don’t think it is the perfect way to build software and I don’t think you can be as rigid as some of the original agile books suggestion. But I do think it is the most well defined software development lifecycle that we currently have. That being said, I tend to fall on Dave Thomas’ “Agile is dead, Long live agility.”

I’ve been a practitioner of agile development for a long time. I’ve participated in tons of Planning Poker, Sprint Planning, Backlog Grooming, Release Planning, etc. I think there is value in each of these processes.

And while I think there are a lot of valuable things about these Agile processes, I have always noticed a few common threads amongst development teams and business users that I’ve worked with when it comes to all these processes.

In the post I’ll be running over a few of the common “pit falls” that I think common agile teams run in to and what I’ve been building to solve these problems.

What is an Epic?

No matter what company I’ve worked for I’ve had to explain what an “Epic” is to many people. Especially business folks. And many of those people I’ve had to tell them multiple times.

But here’s the thing … I’m not entirely sure what an “Epic” is. Look, I get it, it’s a “bigger” piece of work. But that “bigger” has constantly been subjective from person to person. Should an epic span multiple Sprints? Should it be small enough to accomplish in a Sprint? Should it be estimated? These are not “easy” questions to answer. And even if you do answer them, you’re going to have to re-answer them depending on who you’re talking with.

What is a Sprint?

Sprints are obviously the basic building block for agile. The goal of every agile development team is to define what work a team can do within’ this magical allotted time period.

The problem comes in to place when a team has no idea how to solve the technical problem. Most teams, including myself, tend to climb up a technical “hill” while solving a problem. As the progress on solving the problem they tend to gain a better understanding of what it is they are building and how best to solve the problem.

Where does a “User Story” begin?

In the most raw sense of the term, the definition of a user story is meant to be a “place holder for a later conversation.”

However, in practice, what this typically turns into is a dumping ground of random bits of multiple disparate conversations that continually get dumped in to the description of a user story.

The birth of a user story typically begins by the Product Owner (PO), or whomever is acting as the PO (Proxy PO) entering a story in to the Backlog. This story will tend to be a very vague idea of a story. And a majority of the time it’s just the title of the Story contains the general idea. Something like, “Integration with 3rd Party System.”

This is fine, because under the standard Agile definition, “we value Individuals and Interactions over Process and Tools.” Great, we’re on the right track.

The problem tends to come in to place once the Product Owner gets together with the team to discuss this brand new user story during a backlog grooming process.

If a small to medium sized team is blessed enough to have a good scrum master in place to help facilitate the growth and technical break down of this story, things can possibly go smooth. However, even with a good scrum master, the lack of a “good“ scrum master, or most likely no scrum master at all.