A recent question in the Scrum for Team System Q & A site has highlighted that there is a lack of advice on how to accomplish backlog management with the SfTS v3 template. I’ve been working with the template for some time and it all seems very obvious to me, but taking a step back reveals that some of the details are not instantly discoverable. So I’ve decided to dust off live writer and explain how I manage a backlog in SfTS v3…
Note: I briefly describe backlog management in my Getting Started With Scrum for Team System Version 3 blog post. If you haven’t read the getting started guide, I suggest you do so before continuing. Throughout this blog post I will use screen shots from the TFS Workbench utility provided for free by EMC and written by me!
Creating and sizing the backlog.
One of the first steps in the project (long before any development work starts), is to get the ideas buzzing around in product owners head into a list of features that can be worked on by the team. The team then looks at each feature and decides how big it is in relation to all the other features. I can recommend planning poker as a great way to size a backlog.
SfTS v3 suggests that “Story Points” are used to describe the size of the backlog items. Story points are excellent for this purpose as they follow a Fibonacci (ish) sequence (the next number being the sum of the previous 2) and give you a ruff description on the comparative size without an exact figure.
The comparative size of the backlog items is very important. Without knowing the cost, the product owner cannot decide which items should take priority. The backlog generation process should be:
- Product owner creates the initial backlog wish list.
The initial backlog resides at the project planning scope level. Product owners will likely need guidance on describing the feature requests as user stories and should involve the team to ensure that everyone understands the meaning of the story.
A sample backlog
In SfTS the user stories are described by the “Product Backlog Item” (PBI) and “Acceptance Test” (AT) work items. The PBI describes the story requirements and the ATs describe the contract or “condition of acceptance” for the PBI.
Backlog items with linked Acceptance Tests
- Team sizes the backlog.
The team iterates over the backlog items and sets a comparative size to each story. The PBI “Story Point” field is used to capture the size and provides a drop down list of story point values.
Backlog with story points and calculated ROI.
- Product owner prioritises the backlog.
Only when the backlog is sized can the product owner see the cost of implementing features. Once the cost is known, prioritisation should be easier. The PBI “Business Value” field is used to contain the importance of the backlog item and the “Delivery Order” field is used to define the actual sequence of implementation.
Note: The higher the business value the more important the feature.
Backlog with delivery order.
- Release planning.
The product release schedule should be known and the team should have a ruff idea of how many story points they hope to complete in a release. Using this information, the product owner then decides which backlog items should be processed in which release.
Backlog with release schedule set.
The release work item stores the “Estimated Capacity” of story points, sum of planned points and sum of completed (burned) points.
The release work item.
This process is sometimes known as “Sprint Zero”. A pre-sprint process used to get the project scope defined and ready for development.
Epics, themes and stories in SfTS
Your sized backlog will contain a list of stories. A story describes a user centric view of a product feature and is often described using the “User Story” paradigm.
As a <Role> I want <Goal> so that <Benefit>.
The initial product backlog is most likely to be a list of epic stories. An epic is a feature requirement that cannot be completed within a single sprint. This is very normal and expected behaviour, but it does mean that your backlog isn’t going to be very useful for sprint planning. The team needs an appropriately sized backlog in order to select which stories to work on in the next sprint.
What is “appropriately sized”?
Your backlog has a desired sequence of completion, described by a combination of Business Value, Story Points and Delivery Order. The highest priority items are the next to be worked on, so they need to be small enough to fit into a sprint and contain enough detail to describe (in full) the requirement. Future features should be less detailed and larger in size. Future requirements are going to change (this is the nature of agile development), so keeping the requirements general but vague mean that you don’t need to pin down the fine details before they are known.
So when I say “appropriately sized” I mean that the backlog items are sized corresponding to their backlog position. High priority are small with lots of detail, lower priority are large with less detail.
What about themes?
Themes are used to group backlog items that share a common goal. The SfTS template uses “Feature Scope” (AKA Area Path) to describe the backlog item theme. We can use this feature when breaking apart epics to group the smaller stories together.
Splitting epics / backlog grooming
So, you’ve got your epic prioritised backlog. The next step is to groom your backlog by breaking down the high priority epics into bite sized stories that will fit into the sprints. If you were using record cards to model your backlog, then you would write out all the sub stories onto separate cards, rip up the original epic card and toss it in the bin. However, in TFS we have an issue with this. TFS work items are immutable and cannot be thrown out. Once you create a work item cannot be removed. We work around this limitation in SfTS by having a “Deleted” status. Setting a work item to “Deleted” excludes it from the reports and queries.
So, to follow the record card method, here’s how we split the epics.
- Create a new PBI to describe the sub story.
- Assign a feature scope to the new story. (Used to group or theme the sub story with it’s new siblings).
- Assign the story point value to the new story. (The story point value should be comparative to the rest of the backlog).
- Assign acceptance tests to the new item.
- Repeat steps 1 and 4 for each sub story.
- Finally, mark the original epic as “Deleted”.
What if I want to keep my original epic?
If you decide to split off sub stories and maintain your original epic, then make sure you reduce the source epic story point value to reflect the changes. Otherwise, your total backlog story point value will increase with the duplicated cost of both stories!
The backlog will need to be groomed in this manner on a regular basis. This is an important aspect of the backlog life cycle. l like to think of it like a warehouse breaking up a container load of parts ready to be delivered to the factory for processing. It also highlights why the product owner needs to be involved with the backlog through out the life time of the project. The product owner plays the role of warehouse manager feeding the factory with parts.
An example of splitting a backlog item.
In our sample backlog, the highest priority item is “Product browsing and search”. The team has estimated that this story is worth 20 story points. The team also estimate that they can complete 10 story points worth of work in a single sprint. This means that the story is an epic and needs to be broken down before it can be moved in to a sprint.
- Break the epic into logical components.
This story obviously contains “Browsing” and “Search” components. So the product owner (with the teams help) creates 2 new backlog items: “Browsing” and “Search”.
- Set the new sizes.
The team estimate that “Browsing” is worth 13 story points and “Search” is worth 8. Hang on a moment that’s 21 points and the epic was only 20! Don’t panic, remember that story points are a ruff guide to scale and not an exact measurement of size. No harm done.
- Ensure appropriate sizes.
The “Browsing” story is still too big, so the feature is split once again into “Product pages” (5 points) and “Site Structure” (8 points). Now all the items are small enough to fit into a single sprint.
- Theme the stories.
The product owner and team want to track the new backlog items as a single unit, so they create a new project Feature Scope (Product Browsing and Search) and assign it to all browse and search backlog items.
- Prioritise the new backlog items.
Now that the backlog items have been split and sized, the product owner can set the business value and chose delivery order of the items.
- Redistribute the acceptance tests and create new ones as required.
Remember that the backlog is described by both the PBIs and the linked ATs. The original epic had two linked acceptance tests: “Users can browse…” and “User can search…”. So we need to move these tests to the new backlog items. Using the workbench task board mode, drag the ATs to the new backlog items. We also need another test for the new “Site Structure” backlog item, so create a “User can navigate the products” test item.
- Clean up.
The original story still exists on the backlog and the sum of it’s story points is contributing to the release planned total. To clear this up, the epic status is set to deleted.
The backlog is now prioritised and sized appropriately, so it’s time to do some sprint planning.
- Estimate Sprint Velocity.
The team estimate how many story points they can accomplish in the forthcoming sprint.
- Select Backlog Candidates.
The team select backlog item candidates up to the sum of their estimated velocity. The backlog item iteration path is set to the team level for the sprint.
- Generate Backlog Tasks and Estimate Effort.
Generation of the sprint backlog tasks takes place for each selected user story. This includes the not only the tasks needed to develop the feature, but also to those need to test and any other tasks. The sprint backlog tasks should describe all the work needed to complete the backlog item.
- Acceptance Tests and Bugs in sprint planning.
By default, acceptance tests and bugs do not automatically get updated when the linked PBI iteration path is changed. This can cause an issue if you are using the workbench application. The workbench allows you to filter work items by iteration path. If your acceptance tests reside on the root path and you have selected a lower level path workspace then you won’t be able to see the test items. To combat this, you can either manually update the linked tests and bugs paths or create some new Transition Service rules to do it automatically.
De-scoping backlog items
De-scoping work from a sprint in SfTS v3 needs to follow a specific pattern in order for the reports to function correctly.
- Set the backlog item state to “Descoped”.
- The event service automatically updates all “Not Started” tasks to “Descoped”.
- If the backlog item has “In Progress” work, either finish it or manually set it to “Descoped”.
- Save the work items.
- Finally, set the backlog item iteration path back to the release level, ready for inclusion is a subsequent sprint.
Simon Bennett discusses the logic behind de-scoping in his Descoping work in Scrum for Team System Version 3.0 blog post.
That’s it for this post. I hope you found it useful. This guide details how I use the template to manage a backlog. As with nearly all aspects of the SfTS template, you are free to change the behaviour as needed to fit your requirements. So if my way of doing things doesn’t fit well with you, then feel free to adopt your own conventions.
More information on SfTS can be found at: https://www.scrumforteamsystem.com/
Senior Practice Consultant,