Value of smaller user stories??

Last post 12:08 pm July 16, 2019
by Nitesh Bansal
6 replies
Author
Messages
08:46 am July 12, 2019

Dear experts, 

We are working on a new technology recently in our team.

We ran into a problem that DEVs are not able to finish 1 entire user story in the duration of the sprint.

Here is a bit of info about the user story to give you some context: We are building a front end for CRUD operations for an API end point.

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 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 will at least ensure that DEVs complete 1 user story and they will have the impression that at least they did something in the Sprint.

Now my question is:

Is this approach a good apprach?

If yes, are there any other advantages of this approach? Even though, we split it in 4 user stories, there will be lot of common code for these user stories? For product teams, it does not really matter (they don't care). They care about the end product only.

 

Looking forward to your feedback.

11:25 am July 12, 2019

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

12:35 pm July 12, 2019

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.

 

01:13 pm July 12, 2019

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!

 

05:02 pm July 12, 2019

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. 

02:51 pm July 15, 2019

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.

12:08 pm July 16, 2019

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