Give an example of a user story that is negotiable i.e. the N in the INVEST

A user story is a placeholder for a conversation about a possible requirement:

e.g.

As a < type of user >, I want/can/need < some goal > so that < some reason >

As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

I am going to turn your question around and back to you. 

Can you give me an example of a user story that isn't open to negotiation? 

Also, would you be willing to share with us what test and from where the test originated that you found this on?

I've always tried to describe it like this: 



The team should be able to find a better approach to solving a customer problem than the one the PO or other stakeholder originally considered. 



So while all User stories are tecnically negotiable, you want to build that into the story without making it too prescriptive.



So a user story that is not negotiable might look like this:



As a Book buyer

want to be able to rate a book out of 5 stars

So that other people can see the ratings on the book page



While a negotiable story might be:



As a book lover

I want to be able to rate how much I liked a book

So that better recommendations can be made







It's a small change, but the second story doesn't assume who might use the functionality, doesn't lock in the rating system, it doesn't say where that information should be displayed, and it leaves the door open to break this off into other useful functionality (so not just 'here's a rating' but potentially other recommendation systems)



The problem is that many developers will be used to just working to requirements, and so will see a story as what MUST be done. We want to try to push it toward what could be done. 

I'd like to build on Michael Lloyd's example. It could be that, through further refinement, a more helpful story emerges. This could take place before or after work begins to implement the product backlog item.

As a book lover

I want to be able to rate how much I liked a book

So that better recommendations can be made

Members of the Scrum Team should probably have questions about this, unless they are already coming from a position of strong alignment with the needs of their users and customers. And even so, it's likely they would benefit from making their assumptions explicit.

Such questions might include:

• Who will receive the better recommendations? e.g. to the book lover, or to some other persona?
• What is the definition of a "better" recommendation?
  • What different outcomes will we be able to observe, if better recommendations are given?
• Is this really the reason that a book lover would be motivated to rate the book?
  • Or are they driven by something else? e.g. a sense of community/loyalty/goodwill, or some kind of explicit reward.
• Is the book lover intended as the primary beneficiary of this interaction?
  • If not, who is?
  • If it's for other personas, is it necessary/desirable to involve the book lover in this way? Why?
• What other ways do we have of (partially or fully) meeting this need?
  • What are some potential advantages and disadvantages of the various options?

Once multiple options emerge, the way forward is negotiable, and explicit decisions can be made.

N is for Negotiable. A user story is not a contract note. For example, In many teams, particularly when PO and developers are from different vendors, there prevails an expectation that user stories should not change once refined. developers will claim as a change request(CR) if it happens. So a user story should be seen as a card for conversation and open to negotiate when required.