If you have a lot of big user stories, your velocity will jump up and down wildly. This makes it extremely difficult to tell when a user story will be done. Breaking down your huge user stories into smaller ones will help you smooth the flow and give you a clearer picture.
User Stories Start Big
Often you have an idea for a new feature. There is a vague picture in your mind how it could look and work. You put it on the backlog to be able to estimate and prioritize it. Teams new to agile often make the mistake to keep it that way. They assign it a huge amount of story points and start hacking away.
Big User Stories Are Abstract
The problem with this approach is that you skip an important design step in your process. A rough feature idea needs further break down to find out how exactly it should look like. By doing that you will replace the big, abstract story with a lot of smaller, more concrete ones. If your feature idea was “mobile support” you might start breaking it down into stories like “show my location”, “show nearby friends”, etc. These stories will replace the “mobile support” story. Now, it might be possible to estimate those stories. Usually the sum of story points for the descendent stories is bigger than the very vague estimate for the original user story.
Big User Stories Block Your Flow
Another issue of keeping user stories too big is that they will block your flow. If you use one week long iterations a big story might span multiple iterations. That means you deliver 0 story points for a couple of weeks and then suddenly you earn all 40 or so points for that one huge story. Unfortunately even after quite some weeks you have no idea which velocity you could deliver ongoing. Dividing the 40 story points by number of iterations will not cut it.
Only if you use small enough stories, which you can complete within one iteration, will you get a reasonable value for your velocity iteration after iteration. Only then you’ll be able to tell when stories could be finished in the future.