Pordenone - 5 Ottobre 2013
ALM Saturday
Agile planning and
portfolio management su
Team Foundation Server
Gian Maria Ri...
Purpose of the Session
• How to correctly manage «requirements»
• How to scale requirement through the
organization
• Diff...
What exactly «Development
Team» does
Backlog
Prioritized list of everything that might be needed
Single source of requirem...
Team like professional Chefs
Backlog -> Ingredients
Dev Team -> Team of
Chefs
Increment -> Dish
If the backlog is not good...
• I believe the hard part of building
software to be the specification,
design, and testing of conceptual
construct, not t...
Right size requirements
Right Size is important
Big requirements are not estimable
A PBI must fit into an iteration
Big re...
Requirement at Dev
Level
How a requirement is seen by developer
User Story
Requirements as User Story
As a <role> I want <goal> so that <value>
Simple to write, convey core of the concep...
PBI Size
Size of a user Story
Must be implemented in a single iteration
It should contains enough details to be estimated
...
Estimating PBI
Acceptance criteria
Checklist of condition that must be fulfilled to complete the User Story
Good detail le...
Backlog in TFS
How to manage Backlog in Team Foundation Server
Requirement at
management Level
How a requirement is seen by management people
Epics
When a User Story Become Too Big
Decompose in smaller User Stories
Propose alternative smaller solution (T-Shirt Siz...
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 stil...
Epics acceptance criteria
When an epics is Done?
Acceptance criteria are similar to PBIs, just more generic
An epic has se...
Epics in TFS
How to manage Epics in TFS thanks to Enterprise Agile
Planning or Portfolio Management
Executive Requirements
Vision of the product
Contains general directions of the products
Involves investments and funding ...
Agile Theme
Analysis of a Theme
Identify the general needs
Assess the current status of the product
Analyze risks and coun...
Theme in TFS
Customization of template and Enterprise Agile Planning
Kanban and Lean
Flow of states
Each element flow from a status to another
Each column has a maximum Work In Process Limit
...
Kanban in organization
Kanban for epics
Same structure applies to epics
It can potentially aggregate multiple backlog
New
...
Kanban in organization
Kanban for Theme
Prioritization of visions
New
In progress
Done
Chain of consequence
Themes
Themes are decomposed in epics
When a theme transition to in progress it actives its epics
Ep...
Using Multiple teams
in TFS
How TFS 2012 handles multiple team with different types of
self organization
Drum – Buffer - Rope
Iterative is the key
Multiple team can have multiple backlogs but they share a single drum
All teams ...
Backlog is alive
Backlog grooming
At team level it occurs each Sprint
Epics backlog usually span for multiple sprint
Theme...
Feedback tool
Gathering feedback with TFS
Question?
of 28

Porfolio Management in TFS 2013

Published on: Mar 4, 2016
Published in: Business      Technology      
Source: www.slideshare.net


Transcripts - Porfolio Management in TFS 2013

  • 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?

Related Documents