Scrum's definition says that it should be done one story at a time. But, if the team is big enough (say 6+), there are some times where taking just one story is kind of questionable, and it is even more if there are several small stories.
So, sometimes in the team I'm currently working with, we might tackle two stories more often than not. Is this a bad thing?
No it is not bad. During planning meeting team commits to user stories which will be delivered in upcoming sprint. The sprint is safe zone for the team and team decides how to deliver user stories. If it is not possible for all team members to work on tasks from the most important user story (by business priority) it is obvious that they should work on another user story as well to take full advantage of their time capacity.
Btw. where did you find that team should not work on more then one user story at time? You can look on the problem as Scrum master. If team works only on one user story at time and somebody doesn't have any other task to do he is stuck = impediment. How do you solve it as Scrum master? You will remove the impediment by removing the rule so that developer is not stuck any more and can continue on another user story.
I think this rule was probably mentioned as team member should not work on more then one user story at time (except scenarios where work on current user story is blocked by another impediment). That makes sense because context switching in human brain is expensive and disruptive. Also it makes Scrum process much better controlled because you have limited set of user stories in progress. This corresponds with Work in progress limits in Kanban.
There is no such restriction. If the stories are independed of each other , or if the dependeny between them is minimal you can certainly do them in parallel. Of course one member will only work on one story at a time and ideally should only move to the next one after a story is finished. But in case you finish 80% of a story and the remaining 20% is waiting for someone else, you can definetly move on, as long as you can finish coding and testing within the same sprint.
There is no rule in Scrum that specifies how much work the team are allowed to take on at the same time. It's your job to figure out what suits your team best.
Scrum limits work in progress (WIP) over the whole sprint. This means you commit to deliver, for instance, 20 work items this sprint. It doesn't matter how many of them you are working on concurrently as long as you deliver on your commitment.
Compare this to Kanban which also limits WIP, but per workflow state. For instance, the WIP limit for "testing" is 3 for which means that no more than 3 items are allowed in the testing phase at the same time.
