Value of smaller user stories??

Would each of the 4 items satisfy the INVEST criteria for a user story?

It meets most criterias except may be 'I'. There is common code acorss 4 sub stories but they are not necessarily dependant on each other.

Hi Nitesh

That's a great question and one that isn't asked enough in my humble opinion! I think you're on the right lines. Mike Cohn has a downloadable poster for reminding teams how to split user stories here...

https://www.mountaingoatsoftware.com/exclusive/spidr-poster-download

I'm a big fan of small user stories. There's a couple of things that I'd add. If you're teams aren't getting stuff "done" each Sprint then that's not a problem with your velocity charts. The actual problem is that the team hasn't got anything to done and therefore they haven't really learnt anything about the product. Splitting CRUD operations is a classic Agile approach and yes it means you will probably have to revisit some shared code but that's one of the overheads of Agile. The benefit is that after one short Sprint you should have something that is working and done, even if it's just the CREATE part of the entire CRUD "epic". And that means now you know more than you did at the start of the Sprint about how long it will actually take you to deliver the required functionality.

You asked if there are other advantages of this approach. For me, the main advantage is having confidence in your estimates. I've lost count of the number of times development teams I've worked with have been "5 minutes" off getting something done at the end of the week only for it not to end up done the next week or the week after or the week after that. In software development you only really know how long something will take after it's done! By splitting a CRUD operation into (at least) 4 smaller stories you'll have much more understanding of the complexity of delivering the whole once one part is totally done. Plus your users will have the opportunity to inspect working software and give you valuable feedback, even if it's on only part of the overall functionality that they actually want!

I'm not sure I would say i'm an "expert" but I definitely have opinions on a lot of things.  Here is my opinion on this one. 

I would argue that splitting the big story along C,R,U,D lines does stand up the INVEST method.  You said that "I" was in question but delivering C actually is Independent of the RUD stories.  Sure there is some common code but each increment of value can be delivered independent of others. 

As the DEVs are not able to complete the user story in 1 sprint, it is killing our velocity charts and team is feeling about it too.

I feel that a velocity graph should be made up of multiple data points. Using nothing but estimates really doesn't say a lot about their ability to deliver. Now in this situation using leading and trailing data points is going to lead to lower results. But many charts will show peaks and valleys so it is common to chart a trend line and use the normalized data to indicate their abilities to deliver consistently. 

For product teams, it does not really matter (they don't care). They care about the end product only.

This sounds like a really good team and I think you should make it clear that this is a very good thing.  Common code will exists for a lot of development work whether it is creating something new or modifying something that already is in use. 

I can suggest them to break into smaller user stories, in this case, it could be 1 user stories for C, R, U, D of the CRUD.

This could be very helpful. But the team should be careful about the order in which they take on these separate items.

It may be difficult to test that Create is working effectively (and to get meaningful feedback on it), if Read is not yet implemented.

So normally I would be tempted to begin with Read (even if it is only reading data that has to be added separately).

Once Read is available, it might make sense to implement Create next.

It could be advantageous to choose just one Create use case, and implement that as a separate item before doing the rest.

Thanks guys for your useful insights. It really helps to validate personal opinions with the community knowledge.