Although, when we get above the epic/ticket level and onto product management, we inevitable get into the process, product and project parts as well, and eventually we also get into the division of the R&D department into teams and what not, which makes a standardized format challenging. Not impossible, but challenging.
However, there are a few fields that wound benefit from having a stricter - but customizable - definition through some additional configuration file; and specifically status, priority, type.
There's also inevitable going to be different roles needed for different companies, such as creator, owner, assignee, sponsor, so those distinct fields (except maybe assignee) would rather be an array of key/value for the roles.
Only looking at the proposal as-is, I lacked a closed_at field.
The labels and estimate are also challenging; what to accept? Some prefer t-shirt, others story point and some actual durations. And who is allowed to define those?
One thing I've had issues with in all kind of system, are the separation between mandatory, optional and useless fields. In many cases the useless fields are way too many compared to the fields that are actually used for a specific team. Generally, fields tend to lack clear guidance in the tools on who owns them, what to populate them with, and why they exist. Elon Musk once stated that every single requirement must have an owner, and IMHO, so must every single field in the ticket tracking system.
Those things are both company/project/product and team-specific, just as the transitions between the states.
And speaking of transitions, the interesting thing to track against, is rarely the current snapshot of the currently know the requirements, but the changes to the scope, which in turn reflects (from) the company's launch plan.
To generalize, the scope is either increased, decreased or clarified, and that changes all the way from the initial vision statement to the "final" delivery before the EOL and decommsion project has completed.
Although, when we get above the epic/ticket level and onto product management, we inevitable get into the process, product and project parts as well, and eventually we also get into the division of the R&D department into teams and what not, which makes a standardized format challenging. Not impossible, but challenging.
However, there are a few fields that wound benefit from having a stricter - but customizable - definition through some additional configuration file; and specifically status, priority, type.
There's also inevitable going to be different roles needed for different companies, such as creator, owner, assignee, sponsor, so those distinct fields (except maybe assignee) would rather be an array of key/value for the roles.
Only looking at the proposal as-is, I lacked a closed_at field.
The labels and estimate are also challenging; what to accept? Some prefer t-shirt, others story point and some actual durations. And who is allowed to define those?
One thing I've had issues with in all kind of system, are the separation between mandatory, optional and useless fields. In many cases the useless fields are way too many compared to the fields that are actually used for a specific team. Generally, fields tend to lack clear guidance in the tools on who owns them, what to populate them with, and why they exist. Elon Musk once stated that every single requirement must have an owner, and IMHO, so must every single field in the ticket tracking system.
Those things are both company/project/product and team-specific, just as the transitions between the states.
And speaking of transitions, the interesting thing to track against, is rarely the current snapshot of the currently know the requirements, but the changes to the scope, which in turn reflects (from) the company's launch plan.
To generalize, the scope is either increased, decreased or clarified, and that changes all the way from the initial vision statement to the "final" delivery before the EOL and decommsion project has completed.
But, as I mentioned; an interesting concept!