0

I've been using Scrum for some time, but I still do not have a clear understanding of how to handle the case when all team members have different working speed. For example, given an abstract task an employee A will solve it in 5 days while employee B will need about 10 or even 15 days. My team consists of very different (in expertise) people, so they literally work by different speeds.

These are the main misunderstandings:

  • How to measure user stories in ideal man-days because they are very different inside the team? (There are often arguments since some people have experience in the area and some don't so they would need to spend some time reading the docs and doing small steps)

  • Why to calculate team velocity if I would need to calculate each individual's velocity then to be able to give right amount of work to everybody? (Another reason to calculate each individual's velocity is that there is a big difference when a senior guy goes to vacation and a junior)

DemonShi
  • 111
  • 1
  • 6
  • This question is off-topic because it's not within the scope for this site, as defined in [What topics can I ask about here?](//stackoverflow.com/help/on-topic) Also see: [What types of questions should I avoid asking?](//stackoverflow.com/help/dont-ask) You may be able to ask on [another Stack Exchange site](//stackexchange.com/sites#name), for example [pm.se] or [softwareengineering.se]. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Makyen Oct 03 '17 at 23:49

3 Answers3

4

Velocity is merely here so that the team may take a rough guess at the amount of work it can commit to for the next sprint.

Story points only have a meaning relatively to another story, not as an absolute value, because their sole purpose is to draw a broad stroke parallel between stories the team as a whole has completed until now, and stories it will have to deal with in the future.

If a senior developer goes on vacation, just adjust planned velocity for the next sprint accordingly. Don't take it as a pretext to introduce complex estimates, they will only give you a false sense of security and get you deep in a fractal estimation mire, distracting you from your primary goal which is to deliver value.

You don't need to relate story points to man hours. You don't need to calculate team member-specific estimates. You don't need to pre-assign stories to people.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
  • Thank you so much for your answer. But how do I adjust planned velocity if senior developer goes on vacation? Could you explain it in some detail please? – DemonShi Aug 20 '13 at 17:57
  • Velocity * new team size / previous team size minus a few points should do the trick. Really, you don't need to be that accurate. Maybe just plan a bonus story in case the team performs better than expected. – guillaume31 Aug 20 '13 at 18:39
3

Scrum has no concept of individual performance. It's always about the team. You'll always have individuals that perform to varying degrees and if you try and plan for that, it'll drive you slowly insane.

My strong advice is to ignore the performance of the individuals and concentrate on the velocity of the team.

Derek Davidson PST CST
  • 1,799
  • 12
  • 17
0

My 2 cents: All my projects have included Scrums. The best way to handle such case is to let the team members choose their stories and assign them points. 3 point is for story that can be done quickly, perhaps 4 hours or less, 8 point is story that would require a person to complete the story within 1 working day(8 hrs), and 13 point(3 days or less) is the story that will require the person to do some research on implementation, implementing and testing it

There should be lead team developer who understands the working velocity of other team members and can assign the stories to other members based on their ability.

If you think the story will require more than 3 days to be completed, then it should be further divided into mini stories that will require less time to do so.

poodle
  • 107
  • 1
  • 10
  • That is what I was thinking, but that means that team does not need to have a team velocity and user stories would not be estimated in story points during sprint planning. These are the most important Scrum concepts I think. – DemonShi Aug 18 '13 at 20:41
  • BTW, story points usually mean ideal working days, not working hours. – DemonShi Aug 18 '13 at 20:43
  • Perhaps our scrum is a bit customized. User Stories are still estimated during sprint planning. And Each developer is fully involved in adding points to the stories and voices the opinion on his/her ability to choose the story and estimate points for it. – poodle Aug 18 '13 at 21:03
  • And I must add that our development cycle is only 2 weeks. Can't wait for 13 days to complete a story. – poodle Aug 18 '13 at 21:11
  • I see, thanks. Do you divide user stories into tasks? If yes, on which stage? – DemonShi Aug 18 '13 at 22:25
  • @DemonShi Story Points have no relation to units of time. They're an abstract device to help teams size one item of work relative to another. – Derek Davidson PST CST Aug 19 '13 at 18:03
  • @poodle Ideally stories shouldn't be assigned but chosen by team members with collective approval as the sprint goes. If complex stories are always taken by the same team members, the others will never improve. – guillaume31 Aug 19 '13 at 18:19