Skip to main content

Usage Microsoft Team Server Foundation Scrum Template

Last post 12:48 pm January 25, 2019 by Juan Prieto
3 replies
06:31 am January 24, 2019

I am an agile practitioner since I started working in the IT industry.

I am a new Scrum Master and this will be my first time to use Microsoft Team Foundation Server as an Agile Project Management Tool (actually, this is my first to use it ever).

With my previous scrum teams, usually, our Product Backlog is just composed of features the product owner (or even maybe the team for technical stories and debts) wants but with TFS's default Scrum Template, there is a separate board for Features and Backlog Items and it seems that a Backlog Item belongs to a specific Feature.

Is this actually a good thing? I feel like it adds an unnecessary complexity.


08:53 am January 24, 2019

As long as the Product Backlog is the only source of changes to the product and PBI's have their correct attributes, I don't see why this would be a bad thing.

From your description it seems that "Feature" is a group of backlog items, so the tool provides a way to group them to an upper level. A reason for that can be (from the scrum guide):

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Also, 

I feel like it adds an unnecessary complexity.

I see why having two separate boards seems to be adding complexity, however, do the PO / DT feels the same way? As the SM this can be a subject of observation for future sprints and base your thoughts upon evidence before taking action (propose a change, raise the topic on a retro, etc).


09:59 am January 24, 2019

Thanks Juan Prieto for your response.

The way I see it, Features in this sense is essentially what an Epic is, although I think we have a separate board for it as well.

Also, we're trying to follow the Nexus Guide since there are multiple teams working with our product but we have separate product backlogs for each team.

I want to align our process with what the Nexus Guide is saying but is this a deal breaker? We're not really sure if this will going to work since the organization has just adopted agile.


12:48 pm January 25, 2019

If the product is a single product, why is there more than one Product Backlog?

As you may know:

One Product  = One Product Owner = One Product Backlog

This is the same either in Scrum or Nexus. Both frameworks spin around the same product and the product has a single source of changes owned by one PO from where the team (or teams) pull work. To comply with the rules it's important to decide if the product is one product formed by multiple teams or each product is a separate product formed by one team. That is definitely something to sort out the sooner the better.

We're not really sure if this will going to work since the organization has just adopted agile.

One recommendations for nexus is to have previous scrum experience, which means also having knowledge of the agile performance of the teams. I'm not saying that forming a nexus right away and be successful is not possible but not having the basics of Scrum covered within the teams and organization could have a great undesirable impact. Apart form the nexus guide I'd recommend you the book The Nexus Framework for Scaling Scrum. It makes a good job guiding the process on forming a nexus through a case study.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.