Scrum and Visual Studio 2010

5,034 views
4,926 views

Published on

This is the slide deck for my talk at Global Knowledge on 14 May 2010 for Malaysia VS ALM User Group. I was sharing about the new Agile Process Template that is based on Scrum.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,034
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
324
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Add animation and a “can’t commit”… Move a smaller up…
  • Add a not-finished… Red -
  • Add animation and a “can’t commit”… Move a smaller up…
  • Scrum and Visual Studio 2010

    1. 1. Succeeding with Agile Software Development with Scrum<br />Patrick Yong, MVP (SharePoint Server)<br />http://patrickyong.net | i-payong@microsoft.com<br />
    2. 2. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    3. 3. Visual Studio ALM<br />Plan and Track<br />Design<br />Develop<br />Build<br />Test<br />Deploy<br />
    4. 4. Plan and Track<br />
    5. 5. Launching a new project<br />
    6. 6. demo<br />Creating a new Team Project<br />
    7. 7. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    8. 8. What is Scrum?<br />
    9. 9. Roles<br />Product owner<br />Scrum Master<br />Team role<br />
    10. 10. Meetings<br />
    11. 11. TFS Artifacts for Agile Development<br />Work Items and Workflow<br />Queries<br />Dashboard<br />Excel Reports<br />Workbooks<br />Reports<br />
    12. 12. Why Scrum?<br />Iterative Development<br />Lots of small “product releases” over the project’s lifetime<br />As opposed to one major product release at the end<br />Bugs / Problems are found early<br />Products are usable earlier in the process<br />Involves the customer during each iteration<br />Iterative Development lends itself to the Scrum modus operandi<br />Scrum’s artifactpromote customer involvement <br />They allow the customer to re-prioritise the order in which “development” work is done<br />
    13. 13. A word of Warning<br />Some project managers might not like the following slides. Viewerdiscretionis advised.<br />
    14. 14. Waterfall vs. Iterative Development<br />requirement gathering<br />analysis & design<br />development<br />testing<br /> deployment<br />Customer happy, early release?<br />cost <br />of <br />change<br />80% of a product’s value comes from 20% of its features<br />time<br />Managing Iterative Development Using Scrum<br />
    15. 15. Why focus on Iterative Development?<br />Traditional, Waterfall profit & loss cost curve<br />
    16. 16. Why focus on Iterative Development?<br />Iterative Development, early release profit & loss cost curve<br />
    17. 17. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    18. 18. Planning the Project<br />Product Backlog<br />“As a new customer I want to register online so I can use the services offered”<br />User Stories<br />5<br />8<br />Stories are listed on the backlog in priority order<br />The team estimates each story using story points<br />5<br />Priority<br />3<br />New stories are added to the product backlog<br />8<br />1<br />
    19. 19. Product Backlog<br />User Stories<br />Planning the Project<br />Stories are planned for completion in upcoming sprints<br />Sprint 3<br />3<br />3<br />3<br />Sprint 4<br />The product owner re-prioritizes the backlog<br />Priority<br />4<br />4<br />4<br />
    20. 20. Planning Product Backlog<br />
    21. 21. What makes a good user story? <br />INVEST <br />Independent<br />Negotiable<br />Valuable<br />Estimable<br />Small<br />Testable<br />http://www.userstories.com/book<br />
    22. 22. Start writing user story<br />Does your user stories answer the following?<br />Who the user is?<br />What the user need to do?<br />Why the user need to do that?<br />“As a <user>, I need to <action> in order to <reason>”.<br />
    23. 23. Before you rank user stories<br />Small enough to be implemented in the sprint<br />Just detailed enough to describe and estimate the work that is required to implement the story<br />Acceptance criteria defined<br />
    24. 24. Epic and Theme<br />Epic <br />Very large user stories that represent a significant amount of work<br />Theme<br />User stories that are fairly large, generally larger than you would implement in a sprint<br />It must be broken down into smaller user stories.<br />
    25. 25. Spikes<br />Work that is not a direct implementation of a user story. <br />Research<br />Bug<br />Process improvements<br />
    26. 26. Prioritize your user stories<br />First Things First: Prioritizing Requirements<br />http://www.processimpact.com/articles/prioritizing.html<br />
    27. 27. Story Points<br />Story points are a unit of measure for expressing the overall size of a user story<br />Do not translate directly into a specific number of hours<br />Less precise = less effort to determine<br />Do detailed estimation of hours of work later<br />
    28. 28. Velocity<br />Total story points in a sprint<br />A starting point that you can use to determine how many user stories to implement in the sprint.<br />
    29. 29. Estimate Release Plan<br />Remember this:<br />Each sprint, your team will complete an increment of the product that it could ship<br />As such<br />Identify groups of user stories that, together, provide enough business value to release<br />Determine in which sprints the team expects to complete those groups of user stories<br />Note: Its OK to remove/ add user stories to sprint<br />
    30. 30. demo<br />Project planning with MS Excel<br />
    31. 31. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    32. 32. Product Backlog<br />User Stories<br />Planning a Sprint<br />Iteration Backlog<br />User Stories<br />Tasks (hours)<br />Commit!<br />Based on estimates the team commits to each story<br />3<br />3<br />The team thinks this story is more work than they can commit to…<br />During the sprint planning meeting, the product owner and the team add User Stories to the sprint<br />3<br />The team breaks down each story into tasks<br />Commit!<br />Can’t Commit!<br />
    33. 33. Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Planning a Sprint<br />User Stories<br />Tasks (hours)<br />Commit!<br />3<br />3<br />3<br />The larger story is removed from the sprint and the team considers a smaller story on the backlog<br />Commit!<br />?<br />3<br />The sprint is now planned and the team is ready to get started!<br />The team can commit to this smaller story<br />Commit!<br />
    34. 34. Demo<br />
    35. 35. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    36. 36. How do you Run a Sprint?<br />Track Progress<br />Daily Sprint Meeting<br />What work has been completed<br />What work remains<br />Deliver a “potentially shippable” increment<br />Demo the value delivered<br />Retrospective <br />
    37. 37. Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Running a Sprint<br />The team starts work on the tasks…<br />
    38. 38. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Completed work is reported daily<br />
    39. 39. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />
    40. 40. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Each User Story has been implemented<br />All work for the sprint is “done-done”<br />
    41. 41. Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Running a Sprint<br />And the team has developed a “potentially shippable” increment<br />The team holds a demo to show the value they have delivered<br />
    42. 42. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />The latest increment is shipped to customers<br />
    43. 43. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Stories and tasks are cleared from the backlog – the team delivered on its commitment<br />Stories delivered in the last sprint are closed<br />What worked? <br />What didn’t work? What can the team do to improve?<br />The team holds a retrospective…<br />
    44. 44. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />New Stories are added to the Product Backlog<br />
    45. 45. Running a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />The backlog is prioritized and ready for the team to plan the next sprint<br />
    46. 46. Agenda<br />Visual Studio ALM<br />Scrum<br />Planning a project<br />Planning a sprint<br />Running a sprint<br />Reporting<br />
    47. 47. Burndown and Burn Rate <br />
    48. 48. Build Quality Indicator<br />
    49. 49. Test Plan Progress<br />Unhealthy symptoms<br />High no. of test failed<br />No. of passed test remained flat<br />
    50. 50. Bug Status<br />
    51. 51. Bug Trend<br />Healthy trend<br />Bugs discovered early<br />Fewer bugs towardsthe end<br />Bugs resolved faster thanbeing discovered<br />
    52. 52. Stories Overview Report<br />
    53. 53. Story Progress Report<br />
    54. 54. demo<br />
    55. 55. Resources<br />Brian Harry<br />http://blogs.msdn.com/bharry<br />Aaron Bjork<br />http://blogs.msdn.com/aaronbjork/<br />

    ×