SlideShare a Scribd company logo
Presented by Jamie Phillips SCRUM and TFS
Who is Jamie Phillips Senior Software Engineer with over 10 years experience in the Telecomm, e Commerce, Finance and Healthcare industries. Passionate about working with the .NET framework and related technologies (C# 3.5, WCF, Entity Framework, etc.) Natural ability to adapt to change has lead to becoming a practicing SCRUM Master and evangelist.  Blog: http://devblog.petrellyn.com
Who is Picis Global provider of innovative information solutions that enable rapid and sustained delivery of clinical, financial and operational results in the acute care areas of the hospital — the emergency department (ED), operating rooms (ORs), post-anesthesia care units (PACUs) and intensive care units (ICUs). Locations include Wakefield, MA Rosemont, IL London, United Kingdom Barcelona, Spain Website: http://www.picis.com
The SCRUM framework TFS facilitates these Which contributes to these And helps them Product owner Scrum Master Team Roles Release planning Sprint planning Daily scrum meeting Sprint review Sprint retrospective Ceremonies Product backlog Sprint backlog Burndown charts Artifacts
The SCRUM Framework
Product Backlog Requirements / Defects A list of all desired work on the project (Product Backlog Item = Story) Ideally expressed such that each item has value to the users or customers of the product  Prioritized by the product owner in collaboration  with team. Reprioritized on an ad-hoc basis (typically done prior to Sprint Planning and does  not affect  current Sprint) Product Backlog
Product Backlog Item (PBI) Represents a user story that has a business value. Could also represent a Defect (which implicitly has business value)
Sprint Backlog Individuals sign up for work of their  own  choosing Work is never assigned by any individual Estimated work remaining is updated daily. If Product Backlog item is unclear, define an investigative story that will generate more tasks/stories in later sprints (known as a “spike”). Sprint Backlog
Sprint Backlog Item (SBI) Represents a task that a team member will perform to assist the team in completing a story. Should always be related to a Product Backlog Item (PBI); otherwise, what value is it adding to the project?
Product Owner Represents Stakeholders Define the features of the product Be responsible for the value added to the product Prioritize features according to market value  Adjust features and priority every iteration, as needed   Decide on release date and content Accept or reject work results
SCRUM Master Represents the project to management Responsible for enforcing Scrum values and practices Protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint Coaches rather than command and control Acts as a facilitator to remove impediments  Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences (interruptions)
The Team Typically 5-9 people Cross-functional (representation of different skill sets): Developers, testers, documentation, requirements analyst, etc. M embers should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing A sense of ownership / responsibility exists amongst the team members Free flowing communication across all functions Membership should change only between sprints
What is the role of a Manager in SCRUM? Creates business model that works Provides all resources that a team needs Removes impediments that the Team / Scrum Master cannot remove themselves (typically taken from the Impediments backlog) Encourages the team to move beyond mediocrity Can be seen as Invisible hand Oil in the enterprise “engine” Firefighter
Roles are not the same as Positions In SCRUM, roles are intended to serve as the definition of the interaction of particular individual(s) within the SCRUM framework. They are not intended to represent / replace the Positions defined in an organization. Theoretically a Scrum Master could be a Lead Developer or a Manager; just as a Product Owner could also be a Business Analyst. However; a Product Owner should never be a Scrum Master as it would lead to a conflict of interest for the team and the project.
Release Planning Stories are created in QC using the Requirements functionality Story description is of the format   As a  < role >  I want  < feature >  so that  < benefit > Conditions of acceptance contains sufficient detail for the team to create tasks to deliver story feature. Stories that cannot provide sufficient detail in the conditions of acceptance will need to be broken down in to smaller stories
Release Planning (cont) Sizing of stories takes place with involvement from Product Owners and the Team (or at a minimum, technical expertise from Development and Software Quality with sufficient knowledge/experience to be able to size the associated stories). Meeting minutes take note of sizing results for each story and serve as a record for decisions made on story sizing.
Release Planning Tools Quality Center utilizing Requirements Functionality for story creation and sizing. Planning Poker (as needed) – online version available (free): http:// www.planningpoker.com
Sprint Planning Product Owner is present to motivate and discuss Sprint goals at the beginning of the meeting. Team capacity is taken. High priority Defects take precedence over new functionality. Stories or Defects are taken from QC and entered into TFS. Tasks are created in TFS by the team using the “Done, Done” list in order to prevent missing story tasks. Tasks are created as Sprint Backlog Items and are related to a particular story.
Sprint Planning (cont) Team estimates the tasks together, however task estimates may be changed by the task assignee. Capacity is continually updated. Items are pulled from backlog in order of importance/priority. Other team members can, and are encouraged to, facilitate meetings (Sprint Planning, Daily SCRUM). Product Owner is available for questions during planning. Be conservative when estimating tasks.
Sprint Planning (cont) Tasks for shared resources (Doc, RE) are created and estimated by the team.  Scrum Master follows up with resource at a later time. When Sprint Capacity is reached, Sprint Planning is complete. Scrum Master needs to be aware of each members capacity to be sure that no one on the team over commits to tasks in a sprint –  capacity is continually updated .
Sprint Planning Tools Quality Center for both Stories and Defects Team Foundation System for creation of Product Backlog items (Stories) and Sprint Backlog Items (Tasks) Excel for team capacity
Example of Sprint Planning “In Release Defects” High priority “In Release” Defects are “brought in” to  TFS  from  Bug reporting system , representing the team’s commitment to fixing the defect.
Example of Sprint Planning Feature Story User Stories are “brought in” to  TFS  from  Requirements repository , representing the team’s commitment to producing a functional solution to the Story.
Daily SCRUM (Stand-up) SCRUM Master discusses current status of Sprint  Remote team members participate via phone and Web-Ex.  Typically they speak first.  Electronic task board is utilized for the display of tasks, team members point to their tasks  Other team members can, and are encouraged to, facilitate meetings (Sprint Planning, Daily SCRUM) No Laptops  (except for facilitator)
Daily SCRUM (Stand-up) In-depth discussions must be deferred to another time, time is agreed on. Each team members estimated work remaining (statistics) is reviewed to determine if action is needed  The team decides whether a new build should be taken  Product Owner is involved, comes to the Daily SCRUM however is not directly part of the Daily SCRUM
Daily Standup Tools Team Foundation System for Sprint Burndown and Product Burndown Charts. Conchango TaskBoard for identifying tasks associated with each team member. Excel spreadsheet showing remaining hours (using custom Excel Add-In)
Example of Daily SCRUM Team’s progress through the Sprint Backlog is viewed and issues are highlighted.
The Sprint Review Team presents what it accomplished during the sprint to the Product Owner and Stakeholders Typically takes the form of a demo of new features or underlying architecture Informal Whole team participates
The Sprint Retrospective Typically 30-60 minutes Done after every sprint Whole team participates Scrum Master Product owner Team Team discusses: What we did right? What we did wrong? How can we improve? (Select a few items to correct – do not try to commit to all)
Sprint Retrospective Tools Team Foundation System for Sprint Reports, Sprint Burndown Charts and Sprint Retrospective Work Item.
The TFS Process Template Process template is an integral part of Team Foundation Server
Team System Process Templates PBI and SBI are TFS Work Items with a range of fields that can be used for reporting and record keeping. Linking between Work Items is the strength of TFS – a PBI can be linked to a SBI, which can be linked to a number of ChangeSets (each check-in creates a ChangeSet)
Working with a Process Template TFS 2008 comes with two pre-configured Process Templates: Microsoft Solutions Framework (MSF) for Agile Software Development Microsoft Solutions Framework (MSF) for CMMI Process Improvement. Templates can be loaded in the Process Editor of Visual Studio (Team Foundation Power Tools). Add / Remove fields in the Work Item of choice. Upload the template to TFS server (for new projects) “Inject” the changes in to an existing project.
Example of working with Process Template Changes can be made to a Process Template or to an individual Work Item definition.
Questions and Answers
Resources “ SCRUM for Team System” & “Task Board” (Conchango): http://scrumforteamsystem.com/en/default.aspx Team Foundation Power Tools (Microsoft): http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx “ How Do I?” Videos for Team System (Microsoft): http://msdn.microsoft.com/en-us/teamsystem/bb507749.aspx

More Related Content

Scrum And Tfs

  • 1. Presented by Jamie Phillips SCRUM and TFS
  • 2. Who is Jamie Phillips Senior Software Engineer with over 10 years experience in the Telecomm, e Commerce, Finance and Healthcare industries. Passionate about working with the .NET framework and related technologies (C# 3.5, WCF, Entity Framework, etc.) Natural ability to adapt to change has lead to becoming a practicing SCRUM Master and evangelist. Blog: http://devblog.petrellyn.com
  • 3. Who is Picis Global provider of innovative information solutions that enable rapid and sustained delivery of clinical, financial and operational results in the acute care areas of the hospital — the emergency department (ED), operating rooms (ORs), post-anesthesia care units (PACUs) and intensive care units (ICUs). Locations include Wakefield, MA Rosemont, IL London, United Kingdom Barcelona, Spain Website: http://www.picis.com
  • 4. The SCRUM framework TFS facilitates these Which contributes to these And helps them Product owner Scrum Master Team Roles Release planning Sprint planning Daily scrum meeting Sprint review Sprint retrospective Ceremonies Product backlog Sprint backlog Burndown charts Artifacts
  • 6. Product Backlog Requirements / Defects A list of all desired work on the project (Product Backlog Item = Story) Ideally expressed such that each item has value to the users or customers of the product Prioritized by the product owner in collaboration with team. Reprioritized on an ad-hoc basis (typically done prior to Sprint Planning and does not affect current Sprint) Product Backlog
  • 7. Product Backlog Item (PBI) Represents a user story that has a business value. Could also represent a Defect (which implicitly has business value)
  • 8. Sprint Backlog Individuals sign up for work of their own choosing Work is never assigned by any individual Estimated work remaining is updated daily. If Product Backlog item is unclear, define an investigative story that will generate more tasks/stories in later sprints (known as a “spike”). Sprint Backlog
  • 9. Sprint Backlog Item (SBI) Represents a task that a team member will perform to assist the team in completing a story. Should always be related to a Product Backlog Item (PBI); otherwise, what value is it adding to the project?
  • 10. Product Owner Represents Stakeholders Define the features of the product Be responsible for the value added to the product Prioritize features according to market value Adjust features and priority every iteration, as needed  Decide on release date and content Accept or reject work results
  • 11. SCRUM Master Represents the project to management Responsible for enforcing Scrum values and practices Protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint Coaches rather than command and control Acts as a facilitator to remove impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences (interruptions)
  • 12. The Team Typically 5-9 people Cross-functional (representation of different skill sets): Developers, testers, documentation, requirements analyst, etc. M embers should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing A sense of ownership / responsibility exists amongst the team members Free flowing communication across all functions Membership should change only between sprints
  • 13. What is the role of a Manager in SCRUM? Creates business model that works Provides all resources that a team needs Removes impediments that the Team / Scrum Master cannot remove themselves (typically taken from the Impediments backlog) Encourages the team to move beyond mediocrity Can be seen as Invisible hand Oil in the enterprise “engine” Firefighter
  • 14. Roles are not the same as Positions In SCRUM, roles are intended to serve as the definition of the interaction of particular individual(s) within the SCRUM framework. They are not intended to represent / replace the Positions defined in an organization. Theoretically a Scrum Master could be a Lead Developer or a Manager; just as a Product Owner could also be a Business Analyst. However; a Product Owner should never be a Scrum Master as it would lead to a conflict of interest for the team and the project.
  • 15. Release Planning Stories are created in QC using the Requirements functionality Story description is of the format As a < role > I want < feature > so that < benefit > Conditions of acceptance contains sufficient detail for the team to create tasks to deliver story feature. Stories that cannot provide sufficient detail in the conditions of acceptance will need to be broken down in to smaller stories
  • 16. Release Planning (cont) Sizing of stories takes place with involvement from Product Owners and the Team (or at a minimum, technical expertise from Development and Software Quality with sufficient knowledge/experience to be able to size the associated stories). Meeting minutes take note of sizing results for each story and serve as a record for decisions made on story sizing.
  • 17. Release Planning Tools Quality Center utilizing Requirements Functionality for story creation and sizing. Planning Poker (as needed) – online version available (free): http:// www.planningpoker.com
  • 18. Sprint Planning Product Owner is present to motivate and discuss Sprint goals at the beginning of the meeting. Team capacity is taken. High priority Defects take precedence over new functionality. Stories or Defects are taken from QC and entered into TFS. Tasks are created in TFS by the team using the “Done, Done” list in order to prevent missing story tasks. Tasks are created as Sprint Backlog Items and are related to a particular story.
  • 19. Sprint Planning (cont) Team estimates the tasks together, however task estimates may be changed by the task assignee. Capacity is continually updated. Items are pulled from backlog in order of importance/priority. Other team members can, and are encouraged to, facilitate meetings (Sprint Planning, Daily SCRUM). Product Owner is available for questions during planning. Be conservative when estimating tasks.
  • 20. Sprint Planning (cont) Tasks for shared resources (Doc, RE) are created and estimated by the team.  Scrum Master follows up with resource at a later time. When Sprint Capacity is reached, Sprint Planning is complete. Scrum Master needs to be aware of each members capacity to be sure that no one on the team over commits to tasks in a sprint – capacity is continually updated .
  • 21. Sprint Planning Tools Quality Center for both Stories and Defects Team Foundation System for creation of Product Backlog items (Stories) and Sprint Backlog Items (Tasks) Excel for team capacity
  • 22. Example of Sprint Planning “In Release Defects” High priority “In Release” Defects are “brought in” to TFS from Bug reporting system , representing the team’s commitment to fixing the defect.
  • 23. Example of Sprint Planning Feature Story User Stories are “brought in” to TFS from Requirements repository , representing the team’s commitment to producing a functional solution to the Story.
  • 24. Daily SCRUM (Stand-up) SCRUM Master discusses current status of Sprint Remote team members participate via phone and Web-Ex.  Typically they speak first. Electronic task board is utilized for the display of tasks, team members point to their tasks Other team members can, and are encouraged to, facilitate meetings (Sprint Planning, Daily SCRUM) No Laptops (except for facilitator)
  • 25. Daily SCRUM (Stand-up) In-depth discussions must be deferred to another time, time is agreed on. Each team members estimated work remaining (statistics) is reviewed to determine if action is needed The team decides whether a new build should be taken Product Owner is involved, comes to the Daily SCRUM however is not directly part of the Daily SCRUM
  • 26. Daily Standup Tools Team Foundation System for Sprint Burndown and Product Burndown Charts. Conchango TaskBoard for identifying tasks associated with each team member. Excel spreadsheet showing remaining hours (using custom Excel Add-In)
  • 27. Example of Daily SCRUM Team’s progress through the Sprint Backlog is viewed and issues are highlighted.
  • 28. The Sprint Review Team presents what it accomplished during the sprint to the Product Owner and Stakeholders Typically takes the form of a demo of new features or underlying architecture Informal Whole team participates
  • 29. The Sprint Retrospective Typically 30-60 minutes Done after every sprint Whole team participates Scrum Master Product owner Team Team discusses: What we did right? What we did wrong? How can we improve? (Select a few items to correct – do not try to commit to all)
  • 30. Sprint Retrospective Tools Team Foundation System for Sprint Reports, Sprint Burndown Charts and Sprint Retrospective Work Item.
  • 31. The TFS Process Template Process template is an integral part of Team Foundation Server
  • 32. Team System Process Templates PBI and SBI are TFS Work Items with a range of fields that can be used for reporting and record keeping. Linking between Work Items is the strength of TFS – a PBI can be linked to a SBI, which can be linked to a number of ChangeSets (each check-in creates a ChangeSet)
  • 33. Working with a Process Template TFS 2008 comes with two pre-configured Process Templates: Microsoft Solutions Framework (MSF) for Agile Software Development Microsoft Solutions Framework (MSF) for CMMI Process Improvement. Templates can be loaded in the Process Editor of Visual Studio (Team Foundation Power Tools). Add / Remove fields in the Work Item of choice. Upload the template to TFS server (for new projects) “Inject” the changes in to an existing project.
  • 34. Example of working with Process Template Changes can be made to a Process Template or to an individual Work Item definition.
  • 36. Resources “ SCRUM for Team System” & “Task Board” (Conchango): http://scrumforteamsystem.com/en/default.aspx Team Foundation Power Tools (Microsoft): http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx “ How Do I?” Videos for Team System (Microsoft): http://msdn.microsoft.com/en-us/teamsystem/bb507749.aspx

Editor's Notes

  1. Generate tasks (Sprint Backlog Items) for Review and Fix defect Create Test case Review Test Case Execute Test Case Code Review (reviewer) Code Review (reviewee) Update Technical Documentation
  2. Generate tasks (Sprint Backlog Items) for Create new UI Screen Update Application menu to access new UI Code behind for pulling data Create unit tests new data functions Update DB Schema for new data structure Create Test cases Review Test cases Execute Test cases
  3. Show use of TaskBoard and ProjectViewOfTfs (use IMAX project in TFS)
  4. Walk through updating a Work Item in a template and then uploading the template / or injecting the change in to an existing project.