Dtyjlui

Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.

Our team is fairly new to them and trying to figure out how to best apply them?

Here' the problem, per sprint;

• A developer who is dealing with small tickets and requests might complete;

250 x XXS (1) = 250

• The same developer who is working on a large feature might complete;

1 x XL (20) = 20

How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.

Our sizing chart (Fibonacci-ish)

| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |

|------|------|------|------|------|------|------|------|------|

| 1    | 2    | 3    | 5    | 8    | 13   | 20   | 30   | 50   |

Related:

• Why use both story points and hours?


• Story Points to Ideal Days


• Forecasting Story Points in Agile


• Alternatives to estimating in hours/story points

The official answer to the problem is:

There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.

However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?

Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.

With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.

With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.

Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.

Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.

The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.

This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).

In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.

Ok, I will give you a better sizing chart.
I think the problem is that you set up the wrong system.

Before anything, you have to:

• educate your team to give technical estimation and


• take an average for a user story.

Better sizing chart

USER STORY SIZE  TIME ESTIMATE

0                   (-)

1/2                 (<1/2 h)

1                   (1/2 - 1 h)

3                   (1  - 2 h)

5                   (2 - 4 h)

8                   (4 - 8 h)

13                  (8 - 16 h)

20                  (16 - 24 h)

40                  (24 - 40  h)

100                 (40 - 80 h)

Note: team estimate is average of all estimate