tfs2015 - Having how many states is reasonable in TFS PBI workflow? -


my team asking me add these states in pbi workflow.

new, prioritization, design, business review, review, approved, committed, in development, development done, qa testing, ready uat, released uat, uat testing, available in uat, ready production, released, reopen, resolved.

i know can accomplish same using tasks or reason field , have keep workflow "simple" team insisting track using single field (state) clear. know if idea.

i appreciate thoughts , feedback.

we can't how many states reasonable or best. tfs extensible , customizable, designed customers able meet needs of organization.

but know, more states define, more transitions must define. maintenance , further upgrades more complex. changing workflow states of work items, in task , requirement category can cause unexpected challenges in existing functionality future upgrades. changing requirement types (product backlog items , bugs scrum, user stories agile , requirements cmmi) require modification of agile or kanban board. prevent automatic easy template upgrade.

customization should well-thought out, instead of changing existing state field, may consider add new "customstatus" field won't impact existing reports , upgrades.

a blog reference: http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/


Comments

Popular posts from this blog

php - Wordpress website dashboard page or post editor content is not showing but front end data is showing properly -

How to get the ip address of VM and use it to configure SSH connection dynamically in Ansible -

javascript - Get parameter of GET request -