This document summarizes an Agile planning and portfolio management session using Team Foundation Server. It discusses how to manage requirements at different levels, from development teams to management. It explains user stories, epics, acceptance criteria, and how to estimate work. It also covers using Kanban to visualize workflow, and how TFS can support multiple teams through features like backlog grooming, feedback tools, and the drum-buffer-rope approach. The overall goal is to scale Agile practices through the organization using the capabilities in TFS.

1. Pordenone - 5 Ottobre 2013
ALM Saturday
Agile planning and
portfolio management su
Team Foundation Server
Gian Maria Ricci – VisualStudio ALM MVP

2. Purpose of the Session
• How to correctly manage «requirements»
• How to scale requirement through the
organization
• Different level of view for your «requirements»
• Fast feedback and fast cycle

3. What exactly «Development
Team» does
Backlog
Prioritized list of everything that might be needed
Single source of requirements
Never complete
Dev Team
My wonderful product
http://www.url.com
Sprint
Backlog

4. Team like professional Chefs
Backlog -> Ingredients
Dev Team -> Team of
Chefs
Increment -> Dish
If the backlog is not good, the product will be no good
The backlog is the highest value of the product
Bad Backlog lead to bad increments

5. • I believe the hard part of building
software to be the specification,
design, and testing of conceptual
construct, not the labor of
representing it and testing the fidelity
of the representation.
• The hardest single part of building a
software system is deciding precisely
what to build
The mythical man month

6. Right size requirements
Right Size is important
Big requirements are not estimable
A PBI must fit into an iteration
Big requirements documentation are a waste in the system
Independent
Negotiable
Valuable
Estimable
Sized
appropriately
Testable

7. Requirement at Dev
Level
How a requirement is seen by developer

8. User Story
Requirements as User Story
As a <role> I want <goal> so that <value>
Simple to write, convey core of the concept
It contains both the needs of the Product Owner as well as the proposed solution
It is both in the Problem Domain as well in the Solution Domain
It usually do not touch many UI part or many part of the system
As a call center user I want the
system to helps me to insert
correct data into the system so
I can insert more correct data
in a shorter time.

9. PBI Size
Size of a user Story
Must be implemented in a single iteration
It should contains enough details to be estimated
It must give added business value to the product
No dark corner or hidden rocks
As a call center user I want the
system to helps me to insert
correct data into the system so
I can insert more correct data
in a shorter time.

10. Estimating PBI
Acceptance criteria
Checklist of condition that must be fulfilled to complete the User Story
Good detail level, often based on real action done to the system
Can be composed by a series of Test Cases
When I insert some specific data the system should
suggest me the right data to insert
City Names: after the first two letters a suggestion
box with compatible city names should appear
ZIP CODE: Should be automatically populated upon
city insertion
….
OR
• Type two letters in the City textbox and a
suggestion list should appear
• Typing invalid city (ignoring suggestions )turns
the textbox Red
• Upon valid city population Zip Code should be
automatically set
• …

11. Backlog in TFS
How to manage Backlog in Team Foundation Server

12. Requirement at
management Level
How a requirement is seen by management people

13. Epics
When a User Story Become Too Big
Decompose in smaller User Stories
Propose alternative smaller solution (T-Shirt Sizing, Rock Sizing, etc)
Do not lose the original value The story become an Epic
Es: Implement heuristics to validate
data
Really big User Story
Many possible solution of different size
Many part of the system involved
But It is a clear Business Value
Implement Euristics to Validate
Data

14. Epics in form of User Story
Form of user Story is still valid
The form “As a <role> I want <goal> so that <value>” is still valid
It is more generic and conveys a broader concepts
It contains mainly the needs not the solutions
It is almost entirely in the Problem Domain
As a Manager of the Call Center I want the
system to suggest to Call Center Users
potentially bad data with some form of
heuristics. I want also the system to scan
actual data to warn for suspicious data The
system should make it simple to identify
and correct potential errors.

15. Epics acceptance criteria
When an epics is Done?
Acceptance criteria are similar to PBIs, just more generic
An epic has several PBI as Childs
Not all Childs needs to be finished
Kanban board can helps you out
•
•
Manager can find quickly suspicious data
Manager can fix the data and this should make the system "learn"
from this error
• Call Center Users should be warned (not blocked) when heuristic
find some problems
Nice to have
• Heuristic should also "suggest" correction to the data
• Once some Manager does a fix, the system should propose similar
fix in the system

16. Epics in TFS
How to manage Epics in TFS thanks to Enterprise Agile
Planning or Portfolio Management

17. Executive Requirements
Vision of the product
Contains general directions of the products
Involves investments and funding teams
Could comprehend many teams across organization
Requirement metaphor breaks down
There are vague acceptance criteria. Es. The system should guarantee maximum degree of
data correctness
Needs lots of investigation, risk analysis, planning for internal resources
It has no certainty of being implemented (Es. cancellation after risk analysis)
Needs relation to other artifacts
Decomposed in Epic and User Stories
Progress tracking
In agile world usually called Themes

18. Agile Theme
Analysis of a Theme
Identify the general needs
Assess the current status of the product
Analyze risks and countermeasures
Estimate ROI of the theme or Business Value
Express the Vision and Goal with few and simple sentences
A3 problem solving type of analysis (Es Toyota)
Planning and managing running themes
Have a clear and ubiquitous Risk management
Decompose in Epics that in turns will be decomposed in PBI/User Stories
Prioritize Epics
Define Acceptance Criteria for the Epics
Monitor progress of Epics

19. Theme in TFS
Customization of template and Enterprise Agile Planning

20. Kanban and Lean
Flow of states
Each element flow from a status to another
Each column has a maximum Work In Process Limit
Visual and immediate feedback of how the backlog is evolving
It is a pull process not a push process
New
Analysis
Ready
Committed
Testing
Done

21. Kanban in organization
Kanban for epics
Same structure applies to epics
It can potentially aggregate multiple backlog
New
Active
Preview
Acceptable
Closed

22. Kanban in organization
Kanban for Theme
Prioritization of visions
New
In progress
Done

23. Chain of consequence
Themes
Themes are decomposed in epics
When a theme transition to in progress it actives its epics
Epics
Epics are decomposed in PBI / User Stories
Prioritized in order to fulfill the vision of the Theme
When Epics transition to in progress is actives its PBI
PBI
Prioritized to fulfill Epics
Developed with self organization by teams
Common cadence

24. Using Multiple teams
in TFS
How TFS 2012 handles multiple team with different types of
self organization

25. Drum – Buffer - Rope
Iterative is the key
Multiple team can have multiple backlogs but they share a single drum
All teams are synchronized
Development is iterative to gather maximum transparency and feedback
Backlog
Developing
Backlog
Grooming
Feedback

26. Backlog is alive
Backlog grooming
At team level it occurs each Sprint
Epics backlog usually span for multiple sprint
Themes persists for month or even one or two years
Feedback
Backlog is fueled by feedback
Feedback for iteration
Early feedback with UI Mockup

27. Feedback tool
Gathering feedback with TFS

28. Question?