User, User Story, INVEST criteria etc.

A good User Story should pass the INVEST criteria; at least, that is what they teach.

Allen Holub describes a User Story as…

“An expectation from software as expressed by the *end user* so that the software would help the *end user* in his/her **DOMAIN LEVEL WORK**.   
(Paraphrasing is mine, it may not be verbatim as Allen described).

Allen also mentions a popular example of “Login User Story” to describe what is not a User Story.   
“As a user, I want to log in, so that I can update my books of accounts” is not even a User Story, because “Logging in” is not a domain level work for an accountant; otherwise, it would have been covered in textbooks of accountancy.

Now some of these expectations can be expressed by a large number of users, and some by very few users.
Some expectations may take lots of work, and some can be fulfilled with very little work.
Some expectations are technically challenging to implement, and some are quite simple.
Some expectations can be fulfilled, some are impossible to be fulfilled, and some may not be fulfilled because of a conscious decision of the Product Manager.   

They teach that as per INVEST criteria, a good User Story should be

Independent,
Negotiable,
Valuable,
Estimable,
Small, and
Testable.

INVEST is easy to remember. It is a nice sounding mnemonic. One can talk about it for a long time in any "A"gile class. The real question is, how useful this concept is to tackle real world challenges?
Here is my take on INVEST. Needless to say, YMMV.

(1) Independent:

In the very early stage of any new product/project/endeavor, a US can be independent of other USs. But as you progress, any new US would mostly be dependent on some other already built US.  Because we always build some new feature/functionality on top of what is already built.

It is also possible that some US cannot be built unless some other US is built. In short, for the majority of USs in any product this "I" is a myth.

  

(2) Negotiable:

Negotiate actually means … “to confer with another so as to arrive at the settlement of some matter”.    

Settlement? Hmmm… we hear a lot about “Not a Contract but Conversation”.  We do conversations for better understanding and deeper discovery. Deeper discovery will most likely lead to better & more apt functionality/solution.

Provided our focus is not on settlement thru negotiation. 

PO:              With the help of this software, a Regional Manager should be able to assign Sales Targets to Sales Reps. The assigned target is always Quarter-wise & Product-line wise.
Dev Team:   Ok. But can we have the target as a single collective number?

PO:              Ummm. No. That is not how it works.
Dev Team:   I am just trying to negotiate to make it simple.   

PO:              Got it. But that simple implementation is not how the world works.

Dev Team:   I understand. But I am just trying to negotiate. A User Story should be negotiable.

PO:            Good. You have negotiated. But it does not change the expectation of users.
Dev Team:   This is not a good User Story.

PO:              Why?

Dev Team:   It is not negotiable.

 

(3) Valuable:
Some User Stories are extremely valuable for the users; some could be less valuable.

But can you imagine any PO, any team, working on any User Story which does not produce ANY value?

So, why mention explicitly “valuable” as a required attribute of a US?

The folks who teach us about INVEST actually mention that the "V" is for Valuable or Vertical.
{ Translation:  as long as you have a "V" and as long as you can make that cool sounding mnemonic, it is OK }

The same folks who teach us INVEST, also maintain an agile glossary in which there are 2 terms starting with "V"; "Velocity" and "Vesrion Control" but apparently "Value" is not fit to be in that glossary even though it is worth having it in INVEST.  

Every User Story will be valuable is a given; what matters is which US is more valuable than others. Because that influences the RoI, which in turn influences the prioritization. 
islandBRIDGE encourages a PO to assign a value to each User Story like this...

islandBRIDGE suggests using the FPGP mantra to give a ballpark number for the value of a User Story. {Obviously there could be diff/better ways }

(4) Estimable:
Dev Team:   This is not a good User Story.
PO:             Why?

Dev Team:   We can not estimate it. Actually, it is not estimable, so we cannot work on it.

PO:           If you want to know more, ask me more questions, ask for more details. I can provide all details, edge cases, etc. But estimating is something that you can do better than anybody else.

Dev Team:   We already have all the details. But it is not estimable. 
PO:             Ummm

 

(5) Small:
Dev Team:   I fully agree that this is a critical User Story; but because it is big, it does not fit in the required criteria of a good US.

PO:            Of course, there will be big User Stories and small User Stories. We cannot say a US is good or bad depending on the size. BTW, what is that criteria?

Dev Team:   It should be small.
PO:             What?

Dev Team:   Yes. A good User Story should be small.
PO:             OK, how small?

Dev Team:   Small enough to be completed in 2 weeks.
PO:              Completed by whom?

Dev Team:   By us.
PO:             So, what do we do now?

Dev Team:   Split it into small User Stories.
PO:            Maybe you should seriously rethink "what is a User Story". You can split a User Story in small slices; but when you split a User Stories, you will not get many smaller User Stories. You will get many small slices of a single User Story.  
Just like when you split a Country, you do not get many smaller Countries, you get many States of the same Country.
Of course, we can deliver a big User Story,  by delivering many small slices.  
In fact, it is a far better approach to slice a User Story (whether it is Big or Small) and seek early feedback after delivering the first slice or first few slices.

Dev Team:   Yes, that is what we are saying.
PO:           No. You are not saying that. If you say Slices are the same as many small User Stories, then you are using the term “User Story” as a placeholder for a piece of work. And using the term User Story in that fashion has some serious negative side effects.

{Whether a User story is Big or Small, it is always a good practice to make Slices of a User Story, build the User Story Silce by Slice. That way there is an opportunity to build Slices, showcase Slices & keep seeking feedback rather than shipping the entire User Story at one go. This way quick course correction becomes possible and creating big waste can easily be avoided.
islandBRIDGE goes one step ahead and allows to add only Slices in the backlog of a Sprint/Iteration, rather than adding a User Story. In fact, it is very natural for a User Story that few Slices are shipped, few are pending and few could be even dropped as you build and seek feedback. }

  
(6) Testable:
Keep aside a User Story, can there be any functionality/feature, however small,  developed in any software which cannot be tested? Seriously?? 

If someone tells me that this US is not testable, I would say there is nothing wrong with the US; but something wrong with the Tester!

So why explicitly mention that a User Story should be Testable?
Maybe just to have a “T” so as to make that cool sounding mnemonic of INVEST.