It is well-known that poor requirements are the top reason for project failure. For many years, this has been studied by the Standish Group, which produces their famous “Chaos Report” each year. However, the focus is mainly on project failure of traditional or waterfall approaches. My question is: what requirements issues in Agile environments contribute to project failures? In the first of two blogs on this topic: here are 10 problems with requirements in agile:
The User Story is missing
The first item on this list should be so obvious. But apparently, it’s not. It blows my mind when I look at a User Story, and there is nothing included in the description. How can a developer know what to build if there’s no User Story? I don’t care how lazy you are – this is completely unacceptable. There must be a description of some kind, regardless of what format it’s in.
There are no Acceptance Criteria
This is a much more common mistake that I see regularly. I hate to break it to you – having a User Story is just half the battle. Well-defined Acceptance Criteria are also needed to have a whole set of requirements. Acceptance Criteria provide the boundaries of the User Story and serve as the basis for testing. Without a pass/fail set of A/C, how will a tester know what to test, let alone know what success looks like?
One remedy is to have a definition of “ready” for the User Stories. If a story doesn’t include Acceptance Criteria, it shouldn’t be available for development.
Horizontally sliced stories, rather than vertical
This is one of my biggest pet peeves. Seriously. How often does someone have to be trained on Agile practices to remember to slice stories vertically rather than horizontally? When I train agile teams, I often tell them that if they remember nothing else from the training – remember this.
Sadly, I have seen this happening in the real world. It totally makes me cringe. When you slice stories horizontally, you don’t deliver ANY business value until ALL the layers are completed. This is the antithesis of Agile. Moral of the story: always slice your User Stories vertically, with a thin slice through all the system layers. This will deliver a done increment that works from end-to-end and is potentially releasable.
User Stories are written alone in a silo
I have seen both Product Owners and Business Analysts who are guilty of this sin against Agile. User Stories are not meant to be created in a vacuum. Instead, they should be created collaboratively with the Scrum Team.
If one person does write all the stories in isolation, there’s a high chance that you will miss something and that the team will be dependent on that person’s knowledge to understand the stories. Don’t do this!
Work together with your team and stakeholders. Remember, a User Story is just a promise to have a conversation! Also, make sure that a portion of your time each Sprint is spent refining the Product Backlog as a Scrum Team.
Half-baked, poorly written User Stories
It’s bad enough if a User Story is missing, but it’s almost worse when the User Stories are poorly written or half-baked. The format and concept of User Stories are simple, but just like Agile itself, writing User Stories is also difficult to master.
For User Stories at the tactical / execution level, I content that they must have the following components:
- Who – include a specific user or role, not some ambiguous undefined “user”
- What – state what is supposed to happen to trigger the action
- Why – describe the benefit received, which provides context to the developers
There isn’t a definition of “Ready” or “Done”
Most Agile teams have a “Definition of Done,” but some miss the memo. This definition is about the increment itself and can be used as a checklist for completion and acceptance. If you don’t have one for your team, create one NOW!
The “Definition of Ready” is more commonly absent. As a Business Analyst, this is critical for me to understand when a story is truly “suitable for development.” Without a Definition of Ready, stories that aren’t ready can be pulled into sprints. The impact of this is usually churning – questions back-and-forth, delivery delays, and sometimes even stories getting kicked out of the Sprint.
Stories that are too large are allowed into a sprint
This problem has been the bane of my existence with my current client. I joined the team as Scrum Master after development had already been going on for a while. I was shocked when I looked at the Sprint Backlog to see 40-point and 20-point stories. When a story is sized at 13 or higher, I call it a “clue” that the story is too big and needs to be further decomposed. In this case, the developers argued that the story “couldn’t be split up.” I’m going to call BS on that one. There is almost always a way to split large stories.
What was the impact of these large stories? They carried from sprint to sprint, over and over and over again. It was demoralizing for the team and frustrating to the Product Owner and me. I vowed that it would never happen again!
Tip: for some Scrum Teams I have been on, the team agreed to not allow stories over a certain size into a sprint. In most cases, the largest story allowed was an 8, or maybe 13 if the team was large enough or running sprints longer than 2-week sprints.
The focus is on perfection versus “good enough”
I always say: “There’s no such thing as perfect requirements.” I stand by this statement. We are humans, and we always miss something. And that’s OK! When new information is learned, the team can re-plan and adjust accordingly.
Unfortunately, not everyone feels the same way I do about perfection. The key with agile requirements is to get “just enough, just in time.” This means accepting the possibility that you will miss something and that early iterations will be rough. It would help if you learned to accept imperfection and stop at “good enough.”
You forgot to consider your audience
This is a classic sin that I have committed before. Every person and every team you work with will be different. As a Business Analyst (or Product Owner), it is your job to tailor your communications to your audience. You need to understand how they work and what their preferences are. Then, you need to adapt to them.
I once worked with a developer on a mobile application development team who was very impatient. When I started the project, I neglected to ask him what his preferences were for Acceptance Criteria. I began using the Behavior-driven Development style (Given, When, Then) but quickly realized that he was frustrated. Once I realized that he wanted more succinct Acceptance Criteria, I changed how I wrote them. Always cater to your audience.
“Technical” user stories don’t deliver business value
This is another huge pet peeve of mine when it comes to agile User Stories. “Technical” stories are nothing more than an excuse for laziness, in my opinion. User Stories are meant to be written from the user’s perspective – not the developers’! These types of stories don’t deliver any tangible business value to the customer and should not be done.
If you run into this problem, challenge your Developers. Ask them to frame the need up from the customer’s point of view. There is usually a way to incorporate technical tasks in a way that still delivers business value.