lgriffin/gist:6066e66c73ee40e5f22077e75d57e686

## gistfile1.txt
0 : No action required, this could be a non-functional requirement or a validation metric. They should be taken into account but typically the ticket cannot be directly actioned upon and could be closed when the related work is completed.
1 : No tough process required, a trivial change such as a version bump, fixing a typo, etc.
2 : Almost a trivial change but some tough process required, e.g. logging statements and docs update.
3 : Manageable change for 1 person. Relatively easy change which might hit multiple components, some form of research is possibly needed prior to the start of real work.
5 : Possibly a manageable change for 1 person but multiple people could collaborate. Scope might hit multiple components, small amount of uncertainty that might require a spike, sub-tasks are most likely to appear at this point.
8 : Potentially no longer a manageable change for 1 person but an indicator that help might be necessary. Same as a 5 but wit higher uncertainty, meaning a spike is most likely to be required and several sub-tasks should be created.
13 : Large change, spread across multiple components. Unknows are present, we should be hesitant in taking this on until a spike is performed and a small plan must put in place to ensure we can complete it in a sprint and can validate it, otherwise we should split the task.
21 : A complex change with a lot of unknowns, we are not sure about the full scope of the required changes yet. There may be sub-tasks that should be pulled out and examined as standalone issues.
50 : Potentially very large and could be an Epic itself. The full scope of the task is unknown, however we have enough domain knowledge and experience to know it is a large task. The unknowns could be large enough to be standalone issues. This task is not achievable in its current state and a new task should be created to spike it and split it.
100: This is an indicator that the work involved is a feature in its own right. It can also be an indicator that we simply do not have enough information to accurately infer the goal of the ticket. Here we would typically request additional context and comments and push this back to the Product Owner.
	0 : No action required, this could be a non-functional requirement or a validation metric. They should be taken into account but typically the ticket cannot be directly actioned upon and could be closed when the related work is completed.
	1 : No tough process required, a trivial change such as a version bump, fixing a typo, etc.
	2 : Almost a trivial change but some tough process required, e.g. logging statements and docs update.
	3 : Manageable change for 1 person. Relatively easy change which might hit multiple components, some form of research is possibly needed prior to the start of real work.
	5 : Possibly a manageable change for 1 person but multiple people could collaborate. Scope might hit multiple components, small amount of uncertainty that might require a spike, sub-tasks are most likely to appear at this point.
	8 : Potentially no longer a manageable change for 1 person but an indicator that help might be necessary. Same as a 5 but wit higher uncertainty, meaning a spike is most likely to be required and several sub-tasks should be created.
	13 : Large change, spread across multiple components. Unknows are present, we should be hesitant in taking this on until a spike is performed and a small plan must put in place to ensure we can complete it in a sprint and can validate it, otherwise we should split the task.
	21 : A complex change with a lot of unknowns, we are not sure about the full scope of the required changes yet. There may be sub-tasks that should be pulled out and examined as standalone issues.
	50 : Potentially very large and could be an Epic itself. The full scope of the task is unknown, however we have enough domain knowledge and experience to know it is a large task. The unknowns could be large enough to be standalone issues. This task is not achievable in its current state and a new task should be created to spike it and split it.
	100: This is an indicator that the work involved is a feature in its own right. It can also be an indicator that we simply do not have enough information to accurately infer the goal of the ticket. Here we would typically request additional context and comments and push this back to the Product Owner.