Task Distribution Within Team

Unsure if you are either using or experienced in story writing. From your post, it seems that you're tracking tasks, and not stories.

Teams will always be composed of members with different skill sets and experience levels. It is important to promote team identity and growth. There is a ton of information out there to help this process along.

Do you have a Definition of Ready (criteria for a story/task to meet to safely be accepted into a sprint)?

Do you have a Definition of Done (criteria that determines when a story/task is complete)?

It sounds like you are just starting out. While Scrum sounds simple, the practical application of it can be quite complex and challenging.

One thing I would point out though. In Scrum, there is no assigning of work. The team is responsible for completing the work that they've accepted.

The scenario you described, where a less-experienced developer works on a more difficult item, can certainly happen. The question is, what will the "team" do about it if that item is in jeopardy of not finishing by sprint end?

You cannot have a short-term vision as you work through Scrum adoption. So what if a sprint is unsuccessful, and some accepted items did not get finished. What did the team learn through that experience? What are some ways that the team can try to prevent an unsuccessful sprint from recurring?

In Scrum, failure is not an option. It is mandatory. It is foolish to believe that anyone will execute Scrum well right out of the gate.

Failure often creates the right conditions for change. Allow the team to struggle, and be ready to provide encouragement for things done well, and observations around things that aren't going well. Eventually, the team will realize that their lives will be easier if they support each other and work as a team.

Good luck!

Wow, thanks a lot for such a detailed answer, saved it to read thoroughly.

> Problem is, the developers within the team
> have different skills and get tasks done at different speed. 

What team? What evidence is there of any teamwork in this case?

> I thought of not assigning tasks at all - each
> user can choose a task on the board (we use
> Jira), get it done and pick another, but that
> would obvioulsy mean a faster developer will
> select easier/more attractive tasks, while a
> slower developer will get the most difficult part. 

Not assigning tasks would certainly be a step in the right direction. It would remove an impediment to self-organization, though it is unlikely to provide a catalyst for it. I believe you are correct in anticipating that a cherry-picking antipattern is likely to result unless additional action is taken.

I suggest limiting work in progress. The "team" should be coached not to bring any new work into progress as long as existing WIP remains undone, and which they ought to help each other with.

Look at the sprint burndown no later than the next retrospective. Members should check how even the burn is, and how better collaboration might improve it. They should also revisit the "Definition of Done" for the increment and determine if their work is of the best possible release quality.

I agree with Ian Mitchell. If the team is behaving the way you described, that is not a team work. In such case, the WIP Limit will help.

Either way, you can see that the engineer who picks easy items takes more such items, and the engineer who takes the difficult item takes fewer items. In fact, during estimation, the number of story points for a difficult story would be higher than that for an easier story. Thus, what difference does it make if one takes a story of size 5SPs and the other takes 5 stories of 1SP each.

However, everyone has to pitch in if a story has risk of not completing by the end of the sprint and act as a team. That's when, after couple of sprints, for sure, the team falls in the correct paty, i.e. the efficient engineering takes the tough ones and the less efficient engineer takes the easier ones. You can observe these dynamics within the team in 4 to 6 sprints.

Thanks
Ravi Landu

Also agree with Ian and Ravi.

I feel though that it may not be ideal for a team dynamic to evolve where more experienced team members consistently take on the more difficult stories, and less experienced ones take simpler stories. While this may be a necessity in the beginning, the Scrum Master should help the team understand that this is an impediment to team efficiency. It's just reinforcing another type of specialization (experience, skill), like system or domain expertise. Bottlenecks will occur.

What if the business prioritizes more difficult stories at the top of the backlog, but the more experienced team members are unavailable for the next sprint (vacation, etc)? Should the business have to postpone the items most important to them because of specific team member unavailability?

Encourage cross-training, pair programming, and knowledge transfer to help the team mitigate this impediment and lift up other team members.