Independently of the chosen methodology, a team, in order to be agile, is responsible of making choices that take in consideration the values and principles of the Agile Manifesto. Why is this related to reducing the size of a User Story?
Why a team shall invest time in reducing the size of their User Stories?
To discuss this, I would like to reference 4 specific principles from the Principles behind the Agile Manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Working software is the primary measure of progress.
- Simplicity--the art of maximizing the amount of work not done--is essential.
The agile team, focused on delivering working software, will have to understand these principles at the moment of sizing their User Stories. 'Working software' will never be perfect, or complete, but it has to be usable in a sense that your customer or their users can test it and provide you with valuable feedback soon. That is the definition of 'value': The customer doesn't have to wait long before actually seeing some implementations that he can nourish with his input.
How much time shall the team invest in reducing before considering that 'enough is enough'?
It is important that a team makes the effort to analyze the User Story and adapt it. From a practical, daily use point of view, the size of a User Story does matter. If User Stories are too large or too small you cannot use them in planning.
What determines if a User Story is too large or too small?
I believe that there is no definitive answer to that question, however "The ultimate determination is based on the team's knowledge, maturity, motivation, capabilities, and the technology in use". The team, through practice, should target User Stories of about the same size. A good practice about size could be one-tenth to one-sixth of your team's velocity.
For how long?
Well, given the previous Agile Principles, Working software is the primary measure of progress. This principle forces you to make some compromises. If you spend a lot of time in evaluation you won't use that time to produce. Ironically you won't be able to deliver working software at the end of your cycle if you didn't evaluate properly to know if your User Story would fit your sprint.
Remember that Simplicity--the art of maximizing the amount of work not done--is essential. So, try as hard as you can on using some patterns on how to split your User Stories. It is ok if you fail at first but remember the last agile principle I want to share:
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.