How to divide and conquer User Stories

The other day I had a conversation with a colleague on Such little snippets about writing stories. At one point we came to talk about to split user stories. I'm a big proponent of user stories max is 1-2 team business days. My experience is that this gives the stories that are easy for the team to over / through and therefore they can come up with a good and fair estimate.
 

Visible Signs that you need to split your story:

• The team expresses great risks in the form of new technology or external dependencies.
• There are many concrete acceptance criteria. It determines itself what many are, but my guess is more than the 10th
• It takes you more than 5 minutes to explain the essence of Story to the team.
• The team estimate more than 5 story points. 

 

 

Stories Rate

When you break a story, it often occurs that the total estimate rises. It might seem like a silly idea to split now when it comes to "cost" more! 

A high estimate is the uncertainty. Then an estimate of 13 does not just mean 13 story points bum! This means 8-20 story points. Most go to get as accurate plans as possible, so therefore gives a splitting sense. And it may well be that on paper it looks like a bad deal for the PO but he achieves is security. Security to estimate holds. Security that he gets what he wants and that gives business value. And who would not like to have it.
 
So you exchange a small estimate of great uncertainty for a larger estimate of low uncertainty.
 
So my advice to you as Product Owner is to make sure that you make small manageable stores, for both the team's and your own fault. The extra work is well spent.
 
Happy splitting!



Reference : http://blog.devoksne.dk/user-stories-del-og-hersk/