Porfolio Management in TFS 2013

1,413 views
1,174 views

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,413
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
59
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Porfolio Management in TFS 2013

  1. 1. Pordenone - 5 Ottobre 2013 ALM Saturday Agile planning and portfolio management su Team Foundation Server Gian Maria Ricci – VisualStudio ALM MVP
  2. 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. 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. 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. 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. 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. 7. Requirement at Dev Level How a requirement is seen by developer
  8. 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. 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. 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. 11. Backlog in TFS How to manage Backlog in Team Foundation Server
  12. 12. Requirement at management Level How a requirement is seen by management people
  13. 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. 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. 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. 16. Epics in TFS How to manage Epics in TFS thanks to Enterprise Agile Planning or Portfolio Management
  17. 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. 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. 19. Theme in TFS Customization of template and Enterprise Agile Planning
  20. 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. 21. Kanban in organization Kanban for epics Same structure applies to epics It can potentially aggregate multiple backlog New Active Preview Acceptable Closed
  22. 22. Kanban in organization Kanban for Theme Prioritization of visions New In progress Done
  23. 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. 24. Using Multiple teams in TFS How TFS 2012 handles multiple team with different types of self organization
  25. 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. 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. 27. Feedback tool Gathering feedback with TFS
  28. 28. Question?

×