Perhaps I'm missing the point here, but in my experience this is at the core of Scrum:
- For starters, it is on the variety of skills that the team finds its strength
- It is on the coming together of the minds that better solutions are found, not just nice solutions
I'll try to reverse engineer your question a bit, and then seek to land the answer you might be looking for. I hope.
Allow me to clarify the afore mentioned points a bit further:
Typically every person takes a complete user story
Through such statement—as seen on the context of your question—it seems each member takes on the many aspects of a user story on their own. Such idea puzzles me of course, cause if your team has variety of skills, each user story should be touched by as many hands as needed in order to drive it home safely.
The simplest of user stories might merit the brush of a designer, the pen of a copywriter, the mind of a back-end developer and the expertise of a front-end guru; all skills diversely spread over the members of your team.
Thus, you must be endowed with a powerful squadron of "I can do it all myself" Rambo Developers, who can do design, copy, DB entities, server side and client side code. That, or perhaps you are missing the power of a team: its diversity, and the coming together of each member's strengths.
But that's where the strength of a team lies, not the strength of Agile and Scrum per sé.
If it is covered during sprint planning meeting then the meeting will take more than a day to discuss everything
As stated on my second point, it is by the coming together of many backgrounds, skills and ideas that great solutions come about. The perfect time for them to shine the most is precisely during the planning meetings.
A user story is not the same as a requirement. It is meant to be brief and concise, providing an scenario and a use case with it. It is NOT a recipe or set of instructions; it is a problem, a feature, the seed of something that might be but which hasn't been entirely figured out yet.
A product owner comes and bluntly states: "As a user, I'll like for pictures in my gallery to stop getting stretched out". A simple enough use case, but hardly an statement you can say places the dot atop every "i".
- An architect might come and fancy a great solution for it; but he is not day in and day out in the code, so he might miss something out in his fancy solution.
- A tech lead might come and try to use a cannon to kill a mosquito, but that may be a product of being too close to the code day in and day out to lift up his sights and look at a simple enough solution.
- A designer might not know much about how to code the code, but he knows about pictures.
In my experience, Scrum stands out from the pack because of these brief lapses where the team comes together NOT just to apply a solution, but to dream it up as well.
Rest asure, you are bound to get some resistance trying to convince everyone that it is through these planning meetings that you are going to be saving more time than anything else, especially when they drag for much longer than they are used to. Amongst the first arguments you'll get is: "wouldn't it be better if we spent this time coding and... being productive?" At any rate, I know I did. It was only after they had tried everything else, fallen behind several times, failed to get everybody on the same page, and repeatedly underestimated User Stories, that they came back... this time willing to follow along. After all, they didn't have much else to lose :)
Whenever we have applied Scrum correctly good results have not failed to follow shortly after. Instead of getting burnt for trying to borrow the team's time for a couple of hours, now we might run for 4 hours straight and nobody frowns at it. In their own words: "this is good, there are no surprises anymore; everyone knows what everything is about, what everything is for, and what is expected of them." How so? Well, they took part of the solution. That aided in two fronts at once: being truly productive and keeping them engaged during such long meetings; a true win-win situation.
In Short
Following a Scrum methodology, and taking advantage of the strengths it seeks to foster
- you won't have a problem with User Stories that spill over to the next sprint, everyone knows what to do and can get on with it right away
- you won't have a problem transferring over knowledge
- you won't have a problem keeping all members informed
- you are likely to spent more time in planning meetings than before
- you are likely to save you and your team considerable time, misunderstandings and rework by giving up on playing "chinese whispers"
- instead of one pair of eyes, you'll have many pairs of eyes dotting every i and crossing every t
- you are likely to get better and faster solutions through many eyes looking from different perspectives than you would otherwise
