TFS as perfect tool for Scrum (Part 2) – Product Backlog Grooming

This is the second part of the series TFS as perfect tool for Scrum. The series is based on my session that I presented at Microsoft TechDays. You can find more introduction in part 1

The agenda for this series is:

1. Introduction in Scrum and TFS

2. Using TFS for grooming your Product Backlog

3. Using TFS in Sprint Planning

4. Using TFS in your Sprint

5. Using TFS in your Sprint Review and Retrospective

Today, Part 2 – Product Backlog Grooming

Part 2 – Product Backlog Grooming

In part 1 of this series I mentioned the [Product Backlog]. The list of things that should be done in order to create a valuable product. But within Scrum there is no mention of when this Product Backlog is created. It seems that it just appears out of nowhere. In reality this is surely not the case, but the process of filling the [Product Backlog] with rough ideas and preparing for a first sprint is just not in scope of Scrum.

The process of filling the [Product Backlog], prioritizing PBI’s, adding acceptance criteria, splitting up large items is called Product Backlog Grooming. As said, this takes 10% of the time of every sprint. But requirements or features are usually not so well defined and nicely split up the first time they appear on the backlog. Big ideas emerge at several places and most of the time these are not suitable to put on a product backlog. Different departments and different roles have influence on these ideas and they should! This article on Business Analyst Times has a great checklist to improve your grooming quality (http://www.batimes.com/robert-galen/grooming-your-agile-backlogs-for-success.html)

Scrum.org recognizes this and came up with an approach that embraces the fact that software impacts more than the development team. They call this the Continuous Improvement Framework (CIF) and you can read all about this on the Scrum.org website.

When you take a good look at the picture you see that in this picture three departments have a role in the Product Backlog. Product Management puts large ideas on the Product Backlog. As it goes through Program Management the large items become smaller to finally end up as actionable Product Backlog Items that can be built by a Development Team.

Challenges in the “grooming” phase

So back to our Scrum and TFS combination, what are the challenges we are dealing with in the Product Backlog Grooming” phase, and what can we do in Team Foundation Server to alleviate these challenges.

The challenges that I hear the most are these:

• I have different teams, different departments. How do I get one central view on each and every item
• Where do I put my “rough ideas”?
• How can I group my items into “projects” or categories
• How do I create a release
• How do I deal with large PBI’s that won’t fit into a sprint?

As said in part 1, Team Foundation Server is just a tool, which does not solve any of the problems, but it contains several very useful features that allow you to define a process that will!

Use Team Foundation Server

Teams to “split”your Product Backlog

So, let’s take a look at the various departments. The departments contain different people, which all perform different tasks on the Product Backlog but still….It is one backlog. We want one central repository with all our product backlog items on it. But we don’t want to bother everyone with everything all the time.

Team Foundation Server 2012 contains the Team dimension. A Team in TFS is a group of people that you can use to switch context or scope on the same repository. Let’s explain this a bit more by looking at the following picture.

In this picture we see a Product Management Team that creates [Epics] on the product backlog. Epics are big stories that span multiple sprints. I will talk a bit more about epics later in this post. Epics are split up into Product Backlog Items and are transferred to the Product Owners Team. This team might be responsible for adding acceptance criteria or add more details. Then, the Product Owners Team transfers the items to the 2 Development Teams. They both are responsible for adding the PBI to a sprint and eventually building the product.

In the picture all teams look at the same product backlog but at a different level. The Development teams only see the items on the lowest level and do not have to be concerned about items that are still in “design” phase. Surely it is a good practice to tell development teams about the large stories during grooming sessions, but they don’t have to constantly see it.

In TFS we can arrange this with a bit of creativity. As team is not a first class citizen there are different approaches when it comes to teams. There are various good posts about how to deal with this.

• Martin Hinselwood – http://blog.hinshelwood.com/team-foundation-server-2012-teams-without-areas/
• Colin Bird – http://blogs.ripple-rock.com/colinbird/2012/11/19/MultipleTeamsWithMicrosoftTeamFoundationServer2012VisualStudioScrumV2xUpdated1452013.aspx

My approach is the approach describes in the fabulous post of Colin Bird.

In TFS I create 4 teams representing the 4 teams from the picture

In the [iterations] configuration I point the different teams at different levels of my Iteration Tree. Notice that I added [Team] as a level in my iteration tree which differs from the standard approach of Microsoft.

This gives me the following perspective on the TFS Web Access Client

Which is great, because this allows me to drag PBI’s to the backlogs of other teams (Release 1 for PO Team and Team X for Dev Team X). This way you can easiliy sort and order the bigger and smaller items. I can put backlog items in Release 1 (in scope) or put them in a later Release (vNext). You can even have a “dummy” Release [Ideas] to put some draft ideas, to keep them a bit more hidden from the “real”work.

Using “High Level”Backlog Items

In order to have a better distinction between large stories and smaller stories you can use the built-in TFS parent-child features. Once you add a child Product Backlog Item underneath a Product Backlog Item, this is visible in the product backlog as a tree.

To make it bit more sophisticated, you can create a new Work Item Type, for example Epic, and let this Work Item Type be the type that contains your high level stories. To see how to create Work Item Types you can refer to this article for more details.

When using a new work item type, make sure you customize your Agile Boards in TFS in order to see it appear. I wrote a blog post about how to do that here.

Conclusion

Combining the Teams feature in TFS together with the notion of High level and Lower level stories by means of Epics or at least Parent-Child relationships we can quickly review the challenges that I often hear to see if we addressed it all.

• I have different teams, different departments. How do I get one central view on each and every item
  • Use Teams to “split”your product backlog
• Where do I put my “rough ideas”?
  • Create an Epic Work Item Type to store them. To make them even more “invisible” create a Release [Ideas] to store them in
• How can I group my items into “projects” or categories
  • We didn’t really dove into this one, but surely you can use Areas for this purpose or add another custom field
• How do I create a release
  • By using the Teams and the Release hierarchy this can be done fairly easy.
• How do I deal with large PBI’s that won’t fit into a sprint?
  • Splitting up PBI’s works on all levels so also at PO Team level or Development Team level, you can have parent-child PBI’s. Don’t split up to much!! At the most 1 or 2 levels.

If your process needs the distinction between larger and smaller stories and there are various parties that have to deal with it, TFS can be customized to support this.

Resources

• Scrum.org CIF framework – http://www.scrum.org/CIF/
• Martin Hinshelwood TFS 2012 Teams without areas – http://blog.hinshelwood.com/team-foundation-server-2012-teams-without-areas/
• Colin Bird -Multiple teams with TFS – http://blogs.ripple-rock.com/colinbird/2012/11/19/MultipleTeamsWithMicrosoftTeamFoundationServer2012VisualStudioScrumV2xUpdated1452013.aspx
• Creating Work Item Types – http://msdn.microsoft.com/en-us/library/ms404855.aspx
• Change the product backlog in TFS 2012 – https://osnabrugge.wordpress.com/2013/01/04/changing-the-product-backlog-in-tfs-2012
• Grooming your backlog for success – http://www.batimes.com/robert-galen/grooming-your-agile-backlogs-for-success.html