How to handle confusion of "user stories" term in agile methodology?

Question

I find myself in an non-agile environment where "user story" actually means "use case, backed by an excel requirements specification, a testing specification doc, and a few required wireframes || mock ups thrown in". They want to go agile. If the voices in the product owner's ear hear 'user stories' they'll not handle it well. "user story" has years of improper use here.

I thought this would be a fast google, as I doubt I'm the first person to run into this.

How should I handle non-standard use of "user-stories"?

Answer 1

I'd caution against introducing new terminology, as you'll confuse people that are using User Stories correctly. At most, I might try calling them "Agile User Stories" (or Scrum User Stories if you're using Scrum specifically).

Instead, I would counsel you to try to educate those who have the knee-jerk reaction to how the term has been used in the past, and try to help them understand what it means going forwards.

If you don't fight that battle now, you'll be dealing with the impact of introducing non-standard terminology down the road. (getting new hires that do use "User Stories" correctly to understand your terms, getting your people to understand any external books/blogs/training that references "User Stories", dealing with clients that understand "User Stories" but don't know what your new term means, and so on).

Answer 2

They're not user stories. Users are just one type of stakeholder.

Consider CAPTCHA boxes as an example.

As a user
I want to fill in a CAPTCHA box
so that... wait, what? No I don't!

It's not done for the benefit of the user. There's a moderator of the site somewhere who needs this so that he doesn't have to manually wade through a ton of spam. Similarly, some requirements are there for security, or for legal reasons, or auditors, or advertisers, or for performance, or for another 3rd party system, or because the legacy system we're talking to is a pain.

I disagree with Kyle. It's sometimes about users, but often about stakeholders whose goals need to be met for the users to get anything. Internal projects are almost always about delivering benefit to other users and stakeholders. I've been calling them "Stakeholder Stories" for a while (even though they're not stories) and have found that this term helps teams recognize who the real stakeholders are. They usually end up just referring to them as "stories", which is fine by me.

In my experience, the pretence that stories should be focused on users tends to result in other stakeholders' needs being pushed back, or treated only as "Technical Stories" which then have to be delivered alongside others as 2nd class citizens.

Thinking about the business impact and the real stakeholders who need to give feedback can really help to address project risk.

I therefore recommend that a story should be a slice of a feature created in order to either get feedback or gain trust, with the focus on the stakeholder who cares. I like the Feature Injection template:

In order to <achieve a goal>
As <the stakeholder who wants it>
I want <some users to do> <something>.

If you don't have trust of the stakeholders, deliver something to them to show that you can make progress, and gain their trust. If you have their trust, show them something that's likely to need their feedback. It will probably be something new that's not been tried before (or not been tried by very many people).

If you do that, it doesn't matter what you call them. But I'd prefer it not to involve the term "user" unless it really means it.

Answer 3

You might want to consider just using 'case' since people at your business are familiar with the term but just redefining what constitutes a case.

"We're changing how we specify cases" might be an easier sell than "we're stopping doing cases and doing x".

If you think you really need to change the terminology used, one of the following could work.

• Card
• Task
• Feature
• Item
• Increment

Admittedly most of these are used in some agile contexts but they're so general you'd should be OK.