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

This is part of the growing pains seen in organizations transitioning from legacy waterfall to agile.

I've successfully managed several highly complex programs and projects through this in a half-dozen companies.

Initially, let people call things what they want. The names of the steps and processes you follow are less important than efficiently and effectively completing the work against requirements. When you have dazzled management with how well things went, how happy the customer is, you will then have the credibility to reveal what you were actually following.

The next step would be to share your insights with the relevant resource managers and their managers. You may need to suggest they not take your word for it -- bring in a third-party Agile consultant to talk about the benefits of Agile and answer questions. There's more to this transition -- suffice to say it is a dance that can go on for months or years -- especially if you have a traditional PMO that has a lot to lose. If they see you as a threat, you may have to wait for management to come and beg you to reveal your secrets.