Last week on the 27th of November during the Agile London meet up, one of the speaker’s said that “Complexity it’s relative for the problem that we are trying to solve.”
What is true is that since that day, until today I still didn’t stop thinking about this.
This is a great starting point to make teams understand why we should split user stories to a level that the understanding is acceptable and with this reducing the complexity or hidden complexity and risk associated to the implementation.
Beyond Lean Agile 
Stupendous
LikeLike
Reducing the hidden complexity is utterly important. After being involved in a Project where the User Stories were not broken down into smaller units – this really hits home: there was so much that was unknown, that we ended up grooming User Stories during the sprint in an effort to understand them.
LikeLike
Hi Sofia,
I couldn’t agree more with you. Nevertheless, We will have always exceptions where it isn’t possible to breakdown the user story to something smaller but in my opinion all user stories should achieve the level of the INVEST mnemonic, that was created by Bill Wake:
Independent – The user story should be self-contained, in a way that there is no inherent dependency on another user story.
Negotiable – User stories, up until they are part of an iteration, can always be changed and rewritten.
Valuable – A user story must deliver value to the end user.
Estimatable – You must always be able to estimate the size of a user story.
Scalable (small sized) – User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
Testable – The user story or its related description must provide the necessary information to make test development possible.
This way the team will have a quicker and deeper understanding of what is being requested, and should be able to implement and deliver faster than before.
Cheers,
Eduardo
LikeLike