When your Agile Requirements go Wrong, Part 1

Next in my blog series on “Anti-patterns that doom a Product Owner to Fail” is the topic of requirements and how they can go wrong when using Agile. This subject is so large that I’m splitting it into four parts, so it’s more digestible. As a Business Analyst, requirements are near and dear to my heart, so that might explain why I see this problem as so endemic, but it is. So now, let’s get to the first set of reasons Product Owners (or their teammates) get the requirements wrong.

The User Story is missing

Problem

I know, I know – it’s hard to believe, but sometimes there isn’t a User Story at all! For example, there might be a vague description of an Epic or Feature, but that’s not actionable. Nor does it provide the context or reason the work is needed. If you don’t have all the necessary pieces of a proper User Story (who, what, and why), then you’ll never be able to deliver.

Solution

For a User Story to be valuable, it must provide some service or outcome for an end-user. It must also provide the context or the reason the user needs something. It’s okay to start with a high-level User Story Map with “big” concepts, including Epics and Features, but you must decompose those ideas into bite-sized chunks for development. Always include the type of user, the trigger or desire, and the expected outcome as part of your User Stories.

Half-baked, poorly written user stories

Problem

Worse than having no User Story at all is having a poorly written one. I will admit that User Story writing is both an art and a science, and it takes a lot of practice to be good at it – and I mean a lot. Just like Scrum, User Stories are simple to learn but difficult to master. Half-baked User Stories are bound to have lots of holes in them, meaning there will be many follow-up questions, which will result in slower value delivery.

Solution

Practice, practice, practice. And then practice some more. First, get a peer to review and critique your stories. Ask for help to look for appropriate story-splitting patterns that you might apply. Then, run the stories by your audience – your Developers – and ask them if anything is missing or unclear. Always, always, always consider your audience. There’s no one right way to write User Stories, but whatever works for your team is what you should strive to provide them.

Focusing on perfection versus “good enough”

Problem

I started my career in the Waterfall world. I sometimes spent upwards of six months eliciting and documenting requirements, creating what I thought was the “perfect” set of requirements. Well, let me tell you from my experience that there are no perfect requirements. You will always miss something. Likewise, there will always be things you aren’t aware of that might throw a wrench in the works.

Solution

Fortunately, because it’s an empirical process, Agile provides for regular inspection and adaptation. Rather than trying to create perfect requirements, aim for good enough. Although you may have heard the phrase “perfect is the enemy of good” by Voltaire, your MVP doesn’t have to be perfect; it just needs to be good enough to get feedback. Then, you can refine later after you learn whether what you have built is valuable and feasible. I used to be a “pixel perfectionist,” so if you’re a little bit OCD like me, this might be a bitter pill to swallow. But you must let it go and be okay with “good enough.”

“Technical” User Stories that don’t deliver any business value

Problem

So-called “technical” User Stories are one of my greatest pet peeves as an Agile practitioner. It’s my opinion that technical stories should happen few and far between (if ever). Technical User Stories typically don’t provide any direct or demonstratable business value. Your stakeholders will not be impressed when all you show them at your Sprint Review is code. They want to see something that is working, tangible and provides business value.

Solution

All that said, I’m a realist. There are situations where it may make sense to create and develop a technical User Story. However, this should not be a regular occurrence. It should be an exception rather than a rule. Use technical User Stories sparingly and force your Developers to justify why they can’t couch the technical requirements in a story that does provide obvious value to a user. I know that sounds harsh, but if I can, I always try to make sure that even technical work is valuable.

Final Thoughts

Typically, I would summarize what I covered in this blog and ask if you have anything to add. But since this is Part 1 of 4 on the topic of “Agile Requirements Gone Wrong”, I’ll hold off asking that question. This blog is just the tip of the iceberg of ways things can go wrong with your requirements in Agile so check back soon for the next installment.