VSTS Feature/PBI record the release version

Question

I am looking for the easiest way to set up Target version for a Feature or Bug. i.e. this feature will go into release 1.2.3.4.

We have two teams that work across multiple projects all working within a single project iteration.

We use the area path to separate work between the teams, using the areas path set up as such:

• Root
• Root\Foo
• Root\Foo\Area A
• Root\Foo\Area B
• Root\Foo\Area C
• Root\Bar
• Root\Bar\Area X
• Root\Bar\Area Y
• Root\Bar\Area Z
• Root\FooBar\Area M
• Root\FooBar\Area N
• Root\FooBar\Area O

I think ideally to reduce the amount backlog maintenance and complexity time I would like to avoid using the area to record version; - Root\Foo\Area A\1.2.3.4 - Root\Foo\Area A\1.2.3.5 - Root\Foo\Area A\1.2.4.0

I know that I can add in a new picklist(string) field if I customize the process template. This would then give me a single list with all versions across each project:

• Foo 1
• Foo 2
• Foo 3
• Foo 3.1
• Foo 3.2
• Bar 7
• Bar 8
• Bar 9.0.0
• Bar 9.1.1

Whats a good approach, how have you dealt with this requirement?

Thanks in advance!

Answer 1

You just need to add sprints(iteration) and change work item (e.g. feature, bug) Iteration to corresponding sprint.

More information, you can refer to this article: Define sprints

Answer 2

It can be useful to compartmentalise features for marketing purposes.

You should however avoid the trap of using Product Version to refer to these marketing or strategic goals. This is why Microsoft calles each new Windows 10 releases "Anniversary Update" or "Creators Update" and internally refer to them only as milestones. "Redstone 1", "Redstone 2" and the like.

You can easily break your Sprint flow, in Interation Path down into these buckets. This gives you the flexibility to have as many Sprints as you like inside the bucket. If you create /Redstone 2/Sprint 38 you know that everything inside /Redstone 2/ is slated for that release, without specifying either a date or a product version number.

Your Product Owner can then decide when "Redstone 2" has enough features and the level of quality required to ship. Sometimes that is date based, sometimes feature based, but always it is about the Product Owner proxying the business need.