In this case, my team has 3 members and each member has own task. So I decide I have 3 user stories and places them in one sprint. I was very confuse about sprint and user story. Whether I put multi user stories in one sprint or with 1 user stories I will perform in many sprints.
1
-
1This question is a little confusing. Can you elaborate or give us a more detailed example.– Joel Bancroft-ConnorsCommented Aug 4, 2015 at 19:00
Add a comment
|
2 Answers
It's normal for a sprint to have multiple user stories.
You should not have a user story which is too big to be completed in one sprint. In that case it should be broken down to multiple, smaller user stories.
On a side note: You write "I decide I have 3 user stories and place them in one sprint". The user stories in a sprint aren't decided by the scrum master or project manager.
Rather, it's agreed on a "sprint planning meeting" attended by the team and the product owner. The product owner will prioritize user stories and developers will estimate. Finally, developers will commit to a scope of stories that they believe can be completed in one sprint.
If you as PM or SM are writing user stories and deciding sprint scope, you are pretty far from a typical agile lifecycle. Your project won't be benefiting from some of the core advantages of agile, namely the collaboration effort between team and product owner, and self-directed / committed teams.
Are talking about scrum or just in general an agile approach?
I guess from the expression "sprint" one quickly assumes you're talking about scrum and in this context, as Morten K states, it wouldn't be you alone who decides what goes into the current sprint. And yes, there typically would be multiple user stories, only 1 story (or parts of 1) wouldn't fit into what the "agile manifesto" describes. Typically, with each sprint you extend your product with more features/functionality according to the priorities of the customer (product owner).
i guess if you as a PM are just going with a agile PM method in general (not specifically scrum), you can still be in charge of what's part of which iteration, how big your iterations are and how your overall project/product is structured into increments. But even then, you'd ideally go by priorities of customer and you try to eliminate the biggest risks in the first iterations. By splitting the whole projects into iterations/increments you allow the customers to see results much earlier in the project and allow the customer to get involved. The longer your iterations, the more you risk to go into the wrong direction and your customers won't be able to intervene until it's too late.
Maybe have a look at the agile manifesto, it can give you some helpful pointers into the right direction: http://www.agilemanifesto.org/principles.html
