Scrum: who, when and how to breaks up the stories into tasks? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

1. Who breaks up the stories into tasks? B开发者_JS百科y scrum master? or by team members?

2. When to break up the stories? before/during/after the sprint planning?

3. How to break up the stories? By technologies, e.g. data-modeling, sql, or by use cases (each story may have several use cases, and error handling).

Thanks.

---

Who breaks up the stories into tasks? By scrum master? or by team members?

Team members do it. SM facilitates. PO answers questions on "what" and clarifies user story.

When to break up the stories? before/during/after the sprint planning?

Definitely during Sprint Planning. Realistically there might be times when you might have to break stories down into smaller chunks and task them out during the sprint. That would only happen when a team takes up vague stories or high complexity stories. I know taking up vague stories are not recommended and is tough on the team but there might be those rare times when you have to get things started on something. Definitely not after though, it kind of defeats the purpose of tasking by doing it after doesn't it? :)

How to break up the stories? By technologies, e.g. data-modeling, sql, or by use cases (each story may have several use cases, and error handling).

Don't think in terms of functional areas like sql, data modeling, coding, ui etc while tasking. Instead think in terms of use cases, test cases, granular features (remember, tdd way of thinking always helps here). After use cases are all listed known during planning, think what all tasks need to get done to get those use cases, features working. after that, divide those them into chunks of 8 - 16 hours (not more). Off course the use cases could be mentioned as done criteria and should be related directly to the user story being worked on.

---

Who breaks up the stories into tasks?

Team members.

Scrum master on helps or facilitates. They don't build stuff.

When to break up the stories?

During. That's what sprint planning is.

How to break up the stories?

That's the team's choice. Whatever makes sense for getting something done. The point of an Agile method is to actually be Agile and do just the right thing. Following a silly process dogmatically is not Agile.

Read this for guidance on how to interact with your teammates and do planning:

http://agilemanifesto.org/

Actually read it out loud, as a group, at the start of each daily standup until it makes sense to everyone on the team.

---

Who breaks up the stories into tasks? By scrum master? or by team members?

The Project team breaks up stories into tasks. Since they are the ones doing the actual work, they are best equipped to determine what smaller steps are needed in order to complete the story. The scrum masters sole purpose is to serve the team and ensure the process is moving along smoothly. This means calling (not leading) the meetings, removing any impediments, clearing blockages, and anything else that may disrupt the success of the project.

When to break up the stories? before/during/after the sprint planning?

Tasks are broken up in the Sprint Planning meeting before the entire team. The scrum master and Product owner is highly recommended to be present at this meeting to help the team set priorities for the work accomplished. The scrum master isn't required but attending may very well, in my opinion, help him/her do their job better.

How to break up the stories? By technologies, e.g. data-modeling, sql, or by use cases (each story may have several use cases, and error handling).

Tasks should be broken up into completable tasks, that operate in one of two states. Done and Not Done. If a task can easily be caught in some sort of stasis, in limbo of "kinda done but not", and not easily (and very black and white) DONE or NOT DONE, then you need to break it down more. For instance, Complete payment gateway for ecommerce site would be a task because although several things need to take place in order for this to be done (set up secure transaction, integrate payment API into code, create web form, etc.), these all collectively sum up something that can be completed in about 1 or two days. If the payment gateway works fine but is not secure, then the answer to "Is it done?" isn't "well...it's a simple no." At my old job, we tried to make sure that tasks could be completed within 1-2 days, and stories should be completed within the sprint. (if the sprint was 10 days, we tried to have about 5x2-day tasks assocaited with it). i hope that answers ur question.