10 indicators that you might be misunderstanding agile requirements

Nowadays most folks have done some study or got certificated particularly in agile contexts, and although they understand the User Stories concept, it is impressive how many people are still treating User Stories like traditional requirements. This misunderstanding surrounding User Stories may be caused by many different reasons like the company's culture, lack of agile evangelists, etc. 

But the focus of this article isn't why you're misunderstanding User Stories, but to identify if you are indeed doing it wrong.

1 - Writing a complete Story all at once, trying to estimate and get it “right” the first time

Stories evolve as they move closer to sprint execution. I consider a good practice that the team should visit each story (and its offspring) before they make it into sprint planning. This would include grooming meetings and discussions across the team.

The User Story isn't the responsibility of just the analyst or the PO, and if one of these two roles is writing the whole Story by themselves something is wrong.

Teams should take ownership of their backlogs in real-time, thinking about upcoming stories, their interrelationships, their design and test strategies. By doing this on a daily basis, you're creating an emergent nature of agile requirements, design and planning.

2 - If the Product Owner asks for something not articulated on the Story, you split the Story and make them wait for the “Additional Scope”

You expect a User Story to enter a Sprint with no "scope creep" allowed. If the Product Owner or the Analyst forgot something or wants to react to some implemented functionality, they'll get exactly what they asked for and changes get deferred to a new story in next sprint.

This is wrong! User stories are intentionally ambiguous, intentionally incomplete. A User Story should enter the sprint at 70% clarity and exit the sprint at 100% clarity. The point of the 70% is that there should be ambiguity, so things are discussed, clarified and determined during the sprint. The requirement emerges based on conversations. This should not be penalized or deferred, instead, it is the way things should happen in an agile world.

3 - Allowing Stories with very minimal or trivial acceptance tests to enter your sprints

This is a mistake most folks make. One of the most important parts of a User Story is actually the back of the card, in other words, the Acceptance Tests or Acceptance Criteria.

I would say that in sprint planning every story should be submitted to the INVEST and SMART concepts, otherwise it isn't ready for development yet.

Acceptance Tests and Acceptance Criteria help the developers design for what the customer values and help the testers to ensure the story's functionality meets the expectation. It is a good practice to have at least 5 acceptance tests/criteria.

4 - Writing ALL Stories with the [As A – I Want – So That] format, even if it takes an hour or more to do so

The standard format to write User Stories is certainly helpful, but this "rule" is not written in stone. It must be really painful to write a technical User Story using the [As A – I Want – So That] format.

Use the standards when possible and when there is value, otherwise do it in your own way. At the end of the day, a User Story needs to have "words" that have meaning for the team to interpret, estimate and execute towards delivering what the customer needs.

5 - Believing User Stories are only for functional work (Features, Customer Facing Functionality) and not for anything else

I've seen this a lot, and I mean it. This is an illness in User Story writing that needs to be cured. The most significant symptom is a backlog that contains only feature-centric User Stories. No stories focused on infrastructure, technical debt, bug fixing, test automation, refactoring, design, research spikes, nothing.

While the customers LOVE this disease, it ultimately does a disservice for them. It creates narrowly focused products that are typically fragile. The investment in quality in all dimensions simply isn't there.

All work should be crafted in stories and it should always be balanced beyond just features. If you lack discipline, perhaps use the 80:20 rule to help; 80 per cent features and 20 per cent internal investment.

6 - Having a goal to get as many Stories done as possible within each sprint

What should be the goal of each Sprint? Story count, points produced, meeting the Sprint Goal? From my perspective, the customer “drives” in agile teams. And we should primarily measure ourselves by delivering customer value.

If you're delivering stories that have no value to the customer, this is a red signal.

7 - Feeling that Stories have to be complete (100% understood, written, explained) before they enter a sprint for execution

Teams are afraid to say “I don’t know” and/or “We need to do some additional research, prototyping, and experimentation to more fully understand this story and how to decompose it”. The focus is on filling in the template and going through the motions to get a complete story. Very often this takes an incredible amount of time and the team “drops into” design discussions.

This gives the team a false sense of security that was never true even in Waterfall requirements and certainly not true in agile.

Remember the 70% clarity from 2nd topic.

8 - Teams “hold onto” Stories until the very end of a sprint, demo them, and receive feedback on the acceptance of the Stories

Maybe the fear of assuming that the team overestimated some stories will make people hold stories even if the work is already done. Or maybe, this is just the process to be followed so far established by the company's culture.

The truth is that demoing and interacting around Stories should happen all along with their evolution within the sprint. 

9 - The Product Owners or the Analysts must write the Stories until the team “Accepts” them as well-defined

I’ve seen this pattern over and over even within many experienced agile teams. Since the Product Owner "owns" the backlog or since there is an Analyst role in the team, then it’s their responsibility and theirs alone to write all of the stories. And beyond that, their work isn’t “done” until the team accepts the story as meeting their vision on completeness and clarity.

The WHOLE TEAM needs to contribute to the backlog. And the team is not some gating factor for “perfect stories”. That’s simply a Waterfall requirements mindset seeping back into the team’s behaviour. Instead, everyone is responsible for getting their stories ready for execution and delivery.

10 - Thinking that estimates are only good for planning purposes

One of the best ways to move forward in understanding and decomposing a User Story it to throw an estimate via planning poker. Do it as soon as you can. Then have that wonderful discussion around the team as to what they’re thinking surrounding the estimates. Teams too often debate the nuance of a story that’s too large or complex for far too long.

Estimate as quickly and as often as possible. It usually leads to insights at what to do with the story—break it down, run a research spike, let it alone, have some off-line discussions, etc. Always remember, the most important thing in User Story is the “conversation”.