Story pointing using Fibonacci

Question

Currently, our story points field is a free text field. We are finding with no guardrails in place, teams are not taking this field seriously (someone put 10,000,000,000 as their value). With this, we are exploring the option of making this field a drop down with the Fibonacci values only and educating teams on how to use this to story point within our organization to have some standardization.

However, we are wondering how we would change the type of field without creating an entirely new one and deleting the old, along with those story point values. We want to have access to the story point history. Anyone have a workaround for this or have solved for this before? Any suggestions?

Thanks!

Allison Hangge · Answer

Thank you, both!

I apologize - it IS a number field, not free text. With this, Filipi, do you have more information on how we could manage, in a way, the numbers they are entering?

Nic Brough -Adaptavist- · Answer

>try changing it in the database directly on customfield table but you would need to make sure the value currently there are actual numbers

It's more complex than that - number fields store their value in a different columns to the text field.  You'd need to transform all your numbers into the other column as well as changing the field type!

Filipi Lima · Answer

Hello, Allison, how are you today?

The very first thing that came to mind was instructing users to take it seriously.

If for some reason that is not an option, the fact that the field is a free text field could present even more problem as users can start writing things on it.

Next, I would ask if there's any reason your Story Points field is free text as it's usually a number field which you could perform sum operations that can come in handy and prevent invalid data on it.

There's no way to safely change the custom field type in order to keep the history - you could try changing it in the database directly on customfield table but you would need to make sure the value currently there are actual numbers and having a safety backup is a must.

* See Nic's reply, it's more complex than that indeed!

If you're willing to lose the history, you could create a new field and follow these steps to import the current values into the new one.

* https://confluence.atlassian.com/jirakb/how-to-change-custom-field-types-in-jira-158357.html

But honestly, if users are not taking it seriously you'll be constantly having to micro-manage things that shouldn't have too.. so that's where I would start.