Add a number-based estimation

[oliverschuerch]

Description

We estimate our tickets with the sizes tiny, small, medium, large and x-large.
These sizes are relative units (not tied to a unit of time), which is good, but there are several problems with them:

1. They are not based on numbers, which prevents us from creating insight boards on github with summarized/calculated estimations.
2. They have no clear relationship to each other (small is not automatically twice the effort of tiny, etc.).
3. They do not allow us to compare the available person-based time, until the planned release date of v10, with the time required to complete all the tasks.

During the daily, we figured out two different solutions to address all or at least some of the problems described above. Both of them would required to add a new number-typed field on our issues (e.g. Estimation), which then could be used to add an number to each ticket.
However, I think we should keep the size field (tiny, small, etc.) as is for now, but map the new number-based field to the sizes (e.g. tiny = [number1], small = [number2], etc.). We can drop the size field (if the new one works better) in the future.

Github insight boards
Just some examples, that should give you an idea, how the github insight boards could look like.

• Estimation board example
• Feedback board example

The Poll

This poll is about figuring out, what the numbers in the new field should represent.
Please read about the two different solutions below and vote for the one you'd prefer.

Story Points
Story points are a comparative measure. A 3-point story should require roughly three times the effort of a 1-point story, but the exact duration is not implied.

• tiny = 1
• small = 2
• medium = 3
• large = 5
• x-large = 8

Person Day
Person day means, estimating how many days it would take one person to complete a task, making it easier to plan and allocate resources or comparing it with the person days we have available until end of year.
However, it assumes consistent productivity and may not account for complexity or uncertainty as well as other methods.

• tiny = 0.5d
• small = 1d
• medium = 3d
• large = 5d
• x-large = 10d

Estimation Feedback
During our discussions, the idea of ​​adding another number-based feedback field arose.
The idea is that a person who worked on a ticket can indicate whether the original estimate for the issue was correct or the final time required to finish the task was lower or higher than the estimate.

[leagrdv]

Generally, I feel like when we estimate, we already think in terms of the time it takes to do the task. I'd prefer to have a clear person day/size mapping that we agree on and that we all have in mind when estimating. That way, we can keep things as they are, and it would just be a mapping of the sizes to person day to create the graph (so I'd actually vote to keep things as is, but I can't actually change my vote on the poll).
Regarding the feedback field, I would vote against it. IMO, it would be too much effort for no real added value to track everything we do to report on every single task how much we've actually spent.

[oliverschuerch]

For clarification: none of the above options would change how we estimate. Tiny, Small, Medium, etc. would remain. It's really only about adding a number field and mapping the numbers to the above sizes, so it becomes possible to generate a burndown.

[alizedebray]

I’d actually prefer to keep things as is, but any relative estimation scale works for me. If “Story Points” help us create graphs and we think graphs are useful, then let’s use them.

Of course, with any scale we think a bit about time, but the time spent on a task is very different from one person to another, which makes time estimates very inaccurate. Relative estimates are abstract, but they let us look at what our team delivered in the past and use that as a guide. For example, if we finished 3 SM and 1 MD in a week, chances are good we can do the same again next week.

Time estimation is more waterfall, and there are many articles explaining why relative estimation is usually preferred. For example, this one from Atlassian: https://www.atlassian.com/agile/project-management/estimation

[sandra-post]

As mentioned, the WHAT helps to derive the HOW, meaning: Which problem do we want to solve, or which question do we want to have answered?

• Do we want to be able to plan more in advance, so we can make more accurate statements about deadlines, dependencies etc? --> If yes, some metric for effort vs time needed
• Which metric supports this and can work for us? --> I agree with @alizedebray . Relative estimation works by comparing a new task with previously done task(s). Therefore, its a metric based on the known velocity of our unique team.

Estimation feedback
Also here, which problem do we want to have solved, or which question do we want to answer?

• Do we want to know our teams velocity to be able to estimate future tasks? --> If yes, the approach mentioned above (and described by @alizedebray ) already does the trick: If we know after e.g. 1 week the number of finished tasks (with the relative estimate), we have this information already. No additional field needed.

[oliverschuerch]

The WHAT is pretty clear to me: I want to see, whether we're ahead or behind the schedule.
Imo it doesn't matter which number system we would use (story points or person-days), after some time you could already see on the burndown if we're on track or not.

[alionazherdetska]

I agree with @alizedebray - time estimates vary too much between people. Story Points measure complexity/effort regardless of who works on the task, making them more consistent for tracking team progress.

Why no feedback field:
As @sandra-post pointed out, our team velocity already gives us this feedback. If we complete X points per week/month, we know our accuracy.

Proposal:
Let's pilot this for a few weeks with the mapping (tiny=1, small=2, medium=3, etc.) and we'll see if we're ahead or behind schedule on the burndown chart toward the v10 release.

If it works, great. If not, we can adjust.