Scrum and Visual Studio 2010

4,873
-1

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
4,873
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
323
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 />

    ×