Scrum and Visual Studio 2010
Download as PPSX, PDF5 likes2,532 views
This document discusses using Scrum for agile software development. It covers planning a project with a product backlog of prioritized user stories, planning sprints by committing to stories and tasks, running sprints with daily standups and a demo at the end, and reporting on burndowns, tests, bugs, and story progress. Visual Studio tools like work items and queries can help manage artifacts for Scrum projects. Iterative development with Scrum focuses on early delivery of valuable features.
Scrum and Visual Studio 2010
- 1. Succeeding with Agile Software Development with ScrumPatrick Yong, MVP (SharePoint Server)http://patrickyong.net | [email protected]
- 2. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 3. Visual Studio ALMPlan and TrackDesignDevelopBuildTestDeploy
- 5. Launching a new project
- 6. demoCreating a new Team Project
- 7. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 10. Meetings
- 11. TFS Artifacts for Agile DevelopmentWork Items and WorkflowQueriesDashboardExcel ReportsWorkbooksReports
- 12. Why Scrum?Iterative DevelopmentLots of small “product releases” over the project’s lifetimeAs opposed to one major product release at the endBugs / Problems are found earlyProducts are usable earlier in the processInvolves the customer during each iterationIterative Development lends itself to the Scrum modus operandiScrum’s artifactpromote customer involvement They allow the customer to re-prioritise the order in which “development” work is done
- 13. A word of WarningSome project managers might not like the following slides. Viewerdiscretionis advised.
- 14. Waterfall vs. Iterative Developmentrequirement gatheringanalysis & designdevelopmenttesting deploymentCustomer happy, early release?cost of change80% of a product’s value comes from 20% of its featurestimeManaging Iterative Development Using Scrum
- 15. Why focus on Iterative Development?Traditional, Waterfall profit & loss cost curve
- 16. Why focus on Iterative Development?Iterative Development, early release profit & loss cost curve
- 17. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 18. Planning the ProjectProduct Backlog“As a new customer I want to register online so I can use the services offered”User Stories58Stories are listed on the backlog in priority orderThe team estimates each story using story points5Priority3New stories are added to the product backlog81
- 19. Product BacklogUser StoriesPlanning the ProjectStories are planned for completion in upcoming sprintsSprint 3333Sprint 4The product owner re-prioritizes the backlogPriority444
- 21. What makes a good user story? INVEST IndependentNegotiableValuableEstimableSmallTestablehttp://www.userstories.com/book
- 22. Start writing user storyDoes your user stories answer the following?Who the user is?What the user need to do?Why the user need to do that?“As a <user>, I need to <action> in order to <reason>”.
- 23. Before you rank user storiesSmall enough to be implemented in the sprintJust detailed enough to describe and estimate the work that is required to implement the storyAcceptance criteria defined
- 24. Epic and ThemeEpic Very large user stories that represent a significant amount of workThemeUser stories that are fairly large, generally larger than you would implement in a sprintIt must be broken down into smaller user stories.
- 25. SpikesWork that is not a direct implementation of a user story. ResearchBugProcess improvements
- 26. Prioritize your user storiesFirst Things First: Prioritizing Requirementshttp://www.processimpact.com/articles/prioritizing.html
- 27. Story PointsStory points are a unit of measure for expressing the overall size of a user storyDo not translate directly into a specific number of hoursLess precise = less effort to determineDo detailed estimation of hours of work later
- 28. VelocityTotal story points in a sprintA starting point that you can use to determine how many user stories to implement in the sprint.
- 29. Estimate Release PlanRemember this:Each sprint, your team will complete an increment of the product that it could shipAs suchIdentify groups of user stories that, together, provide enough business value to releaseDetermine in which sprints the team expects to complete those groups of user storiesNote: Its OK to remove/ add user stories to sprint
- 30. demoProject planning with MS Excel
- 31. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 32. Product BacklogUser StoriesPlanning a SprintIteration BacklogUser StoriesTasks (hours)Commit!Based on estimates the team commits to each story33The team thinks this story is more work than they can commit to…During the sprint planning meeting, the product owner and the team add User Stories to the sprint3The team breaks down each story into tasksCommit!Can’t Commit!
- 33. Product BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Planning a SprintUser StoriesTasks (hours)Commit!333The larger story is removed from the sprint and the team considers a smaller story on the backlogCommit!?3The sprint is now planned and the team is ready to get started!The team can commit to this smaller storyCommit!
- 34. Demo
- 35. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 36. How do you Run a Sprint?Track ProgressDaily Sprint MeetingWhat work has been completedWhat work remainsDeliver a “potentially shippable” incrementDemo the value deliveredRetrospective
- 37. Product BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Running a SprintThe team starts work on the tasks…
- 38. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Completed work is reported daily
- 39. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)
- 40. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Each User Story has been implementedAll work for the sprint is “done-done”
- 41. Product BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Running a SprintAnd the team has developed a “potentially shippable” incrementThe team holds a demo to show the value they have delivered
- 42. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)The latest increment is shipped to customers
- 43. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)Stories and tasks are cleared from the backlog – the team delivered on its commitmentStories delivered in the last sprint are closedWhat worked? What didn’t work? What can the team do to improve?The team holds a retrospective…
- 44. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)New Stories are added to the Product Backlog
- 45. Running a SprintProduct BacklogIteration BacklogUser StoriesUser StoriesTasks (hours)The backlog is prioritized and ready for the team to plan the next sprint
- 46. AgendaVisual Studio ALMScrumPlanning a projectPlanning a sprintRunning a sprintReporting
- 47. Burndown and Burn Rate
- 49. Test Plan ProgressUnhealthy symptomsHigh no. of test failedNo. of passed test remained flat
- 50. Bug Status
- 51. Bug TrendHealthy trendBugs discovered earlyFewer bugs towardsthe endBugs resolved faster thanbeing discovered
- 54. demo