Just had a quick question about Agile Development in terms of number of assigned user stories - per developer - in a sprint...
The gist is this: in a 10 day sprint, I had 2 stories that were assigned to me. The stories were very much related, and the second story clearly piggy-backed off of the first.
In Agile Development, is it acceptable to have worked on the initiative / acceptance criteria of both stories in one branch, and have the logic for both stories pushed up for a pull request / code review in that same branch.
The 2 user stories do have their own individual story numbers in our sprint management software. The first story was essentially rendering a component with 2 links, and the second story was making those links either go to a specific route (condition 1), otherwise they are each to open up a specific modal (condition 2).
During my code review, one of the devs asked why I did this, and suggested I should have waited for the first story to be not only code review approved, but accepted by QA before even beginning to work on the second story, saying that I added unneeded complexity for QA, and delayed the chances of the stories being accepted in the current sprint.
My argument was that (besides the constant and unnecessarily long time it takes for the code review), it did not make sense to finish the first story, then sit around and wait for it to be accepted before beginning the development on the second, ESPECIALLY due to the simplicity of it.
The flip side, had I started developing the second story, there would have either been unnecessary duplicate code (to render the necessary component from the first story) to test the new logic, or lots of going back-and-forth between branch-1, branch-2, and develop; not to mention using git rebase (which I'm down with, just sayin) on each branch (git pull new changes into develop, run git rebase develop on branch-1, then run git rebase branch-1 on branch-2. Just seems convoluted)
To be more efficient, and because of the minor criteria of the second story, I did all of the coding efforts in a single feature branch.
Whew! This was far more long-winded than I intended; sorry about that...
TL;DR -- is it ok for a developer to work on more than one separate user stories at the same time during a sprint, in a single feature branch? So long as they are very closely related and piggy-back off of each other..?
It sounds as if the user stories were mis-defined in the first place: From the user's perspective, what's the point in having a link in the UI that does not point anywhere? This is the situation you would have ended up with if your story1 got implemented without story2. I.e. what you refer to as user stories are not in fact user stories, but two tasks that belong to a single user story. To resolve the situation, this should be reflected in the management software.
But more generally, after the sprint planning meeting, there should be no questions left open regarding who does work on what tasks.
Answering your question, in general of course it is ok to work on more than one user story, but inside the team it should be clear to everyone who does what before one starts the work, and the general organisational conditions (QA of user stories, in your case) should be taken into account. Communication is key. If you think the user stories should be structured differently or some things do not make sense in isolation, let the others know about your opinion before you start working on it. The sprint planning meeting is the best time for this kind of discussions, but your scrum master should always be open to discuss. This way of handling stuff should avoid surprises for your teammates.