This document discusses using Scrum and Visual Studio 2010 for agile software development. It provides an overview of how to plan a Scrum project using Visual Studio templates, including organizing product backlogs, sprints, daily scrums, and sprint reviews. It also lists common agile practices like test-driven development, continuous integration, and refactoring that can be applied.

1. work agile
with
scrum
and
visual studio 2010

2. 1 scrum
2 visual studio 2010
3 agile practices
engineering practices
testing practices
architecture practices
… practices

3. scrum
an iterative, incremental approach to optimize
predictability and control risk.

4. must read
and these

5. must read
must studied

6. requirments
waterfall design
development
testing
user acceptance
release
sprint 1
scrum
sprint 2
sprint 3
sprint 4
sprint 5
release

7. scrum support
in visual
studio

8. This template allows you to organize and track the
progress and health of a small- to medium-sized
Scrum project.

10. team
1 product owner
1 scrummaster
5± 2 the team

11. the team
the Team, which does the work. The Team
consists of developers with all the skills to
turn the Product Owner’s requirements
into a potentially releasable piece of the
product by the end of the Sprint.

12. product owner
the Product Owner, who is responsible for
maximizing the value of the work that the
Scrum Team does.

13. scrum master
the ScrumMaster, who is responsible for
ensuring the process is understood and
followed.

14. pig & chicken
“A chicken and a pig are together when the chicken
says, "Let's start a restaurant!"
The pig thinks it over and says, "What would we call
this restaurant?"
The chicken says, "Ham n' Eggs!"
The pig says, "No thanks, I'd be committed, but
you'd only be involved!"

15. # Planning the project

16. # Release planning
meeting
Estimating and prioritizing the Product Backlog
# Product Backlog
Evolving
User Needs
Owned by Product Owner
Prio by Business Value

17. product backlog
The Product Backlog represents everything
necessary to develop and launch a successful
product.
It is a list of all features, functions, technologies,
enhancements, and bug fixes that constitute the
changes that will be made to the product for
future releases.

18. # Product Backlog in visual studio

19. # Product Backlog

20. # Product Backlog

21. work item type
product backlog item
bug
# Product Backlog

22. product backlog item

23. bug

24. tip: product backlog items are usually stated as
user stories. use cases are appropriate as well,
but they are better for use in developing life-
or mission critical software.
www.scrumalliance.org

25. bugs on the backlog
scenario: bugs are related to functionality being
coded during the sprint
solution: bugs are solved during in the sprint - speak
or create task -
scenario: bugs are not related to functionality being
coded during the sprint
solution: bugs on the backlog.
solution: bugs on a separate bug backlog.

26. Iteration path
# Product Backlog

27. Iteration path

28. Iteration path

29. done
The increment must be a complete slice of the
product. It must be “done.”
Done defines what the Team means when it
commits to “doing” a Product Backlog item in a
Sprint.

30. grooming the backlog

31. release burndown graph
The Release Burndown graph records the sum of
remaining Product Backlog estimated effort across
time.

32. velocity graph
velocity is how much product backlog effort a team
can handle in one sprint

33. Looking ahead to the next version of VS Application Lifecycle Management

34. # Planning the sprint

35. # Sprint planning
meeting
Add PBI to sprint
Decomposition
Commitment
# Sprint Backlog
Tasks
Related to PBI’s
Hours remaining

36. sprint backlog
The Sprint Backlog consists of the tasks the Team
performs to turn Product Backlog items into a
“done” increment.

37. # Sprint Backlog in visual studio

40. task
It is all of the work that the Team identifies as
necessary to meet the Sprint goal.

41. task

42. sprints

43. sprints

44. sprint burndown graph
Sprint Backlog Burndown is a graph of the amount
of Sprint Backlog work remaining in a Sprint across
time in the Sprint.

46. team capacity planning (from MSF)

47. sprint burndown graph in Excel from MSF

48. sprint planning in Excel from MSF

49. Looking ahead to the next version of VS Application Lifecycle Management

50. # Daily scrum
Track
# Running the sprint

51. daily scrum
The Daily Scrum is at the same time and same
place throughout the Sprints.
During the meeting, each Team member explains:
1. What he or she has accomplished since the last meeting;
2. What he or she is going to do before the next meeting; and
3. What obstacles are in his or her way.

52. scrum boards
AIT Taskboard
http://www.aitgmbh.de/
Urban Turtle – Agile Planning Tools
http://urbanturtle.com/

53. Looking ahead to the next version of VS Application Lifecycle Management

54. Looking ahead to the next version of VS Application Lifecycle Management

55. practices
Test early and often
Build and deploy continuously
Acceptance Test Driven Development
Emergent Architectures
Refactor
Test Driven Development
Agile Database Development
Pair Programming

56. # Ship the sprint

57. # Sprint Review
Demo the value
# Sprint
Retrospective
Agile Practices – Improvement
# Product
Tasks
Related to PBI’s
Hours remaining

58. sprint review
During the Sprint Review, the Scrum Team and
stakeholders collaborate about what was just
done. Based on that and changes to the Product
Backlog during the Sprint, they collaborate about
what are the next things that could be done.

59. sprint retrospective
This meeting, the ScrumMaster encourages the
Scrum Team to revise, within the Scrum process
framework and practices, its development
process to make it more effective and enjoyable
for the next Sprint.

60. sprints
# Sprint
Retrospective

62. practices

63. practices
Test early and often
Test Driven Development
Acceptance Test Driven Development
Build and deploy continuously
Emergent Architectures
Refactor
Agile Database Development
Pair Programming
… and more

64. Test early and often
Test Tasks,
get test early involved

65. Test Driven Development
Write unit test before code

66. Acceptance Test Driven Development
Write acceptance tests before code

67. Build and deploy continuously
Deliver continuous work software

68. Emergent Architectures
Design vertical slices of functionality
No Big Design up Front

69. Refactor
RED GREEN REFACTOR

70. Agile Database Development
Database unit tests
Database refactoring

71. Pair Programming
The person typing is called the driver. The person
reviewing the code is called the observer

74. staat voor resultaat