0

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!

Helix 88
  • 701
  • 6
  • 19
  • 2
    If you use Scrum, why do you need to know in which version a functionality will land? What you want is to release a working software at the end of a sprint, in each sprint a set of PBIs/Bugs are completed and integrated into the software, hence just set the Sprint (it is the Iteration field of the work item) on each PBI/Bug: that Sprint is the target, whatever version of the software come out of it. – Luca Cappa Jan 05 '17 at 16:39

2 Answers2

0

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.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
-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

starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53