Scrum is not a new concept but it has gained a lot of popularity in the last few years. It is a very powerful agile project management methodology that, when used correctly, can help your team deliver better software faster than before. We will start with a brief overview of the process and look at some techniques and tools that will help you succeed, as well as common pitfalls that you should avoid. Come prepared for an interactive session where you will be encouraged to share your experiences with Scrum.

1. Scrum Intro and overview

2. What is Scrum? Agile development methodology Helps cross-functional teams commit and deliver high-quality, production-ready code in phases Scrum is an iterative process for developing any product or managing any work, which produces a potentially shippable set of functionality at the end of every iteration. Scrum engages developers to produce the major pieces of an application in less time than by traditional methods

3. Characteristics Self-organizing teams Product progresses in a series of two- to four-week “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects One of the “agile processes”

4. Scrum goals Team environment & communication Quality product Provide more information on project progress early on Ability to adjust to business needs

6. Major changes due to business needs are not easily incorporated into the design

8. Time boxes Release Planning Meeting Sprint Sprint Planning Meeting Sprint Review Sprint Retrospective Daily Scrum

9. Process Sprint planning meeting Allows product owner and team to see what will be delivered Team addresses “What” and “How” Sprint goal is set Items are moved from the product backlog into a sprint Sprint backlog is created

10. Process Daily Scrum meetings Allows team to see entire picture everyday Short meeting, team members answer the following: What did I work on since the last meeting? What will I work on until we meet again? What impediments are preventing me from getting my tasks done? Not a status meeting

11. Process Sprint review meeting Occurs at the end of the sprint Product is demo’d Product owner can accept/reject the deliverables Review Product backlog at the end

12. Process Sprint retrospective Discuss what went well and what to improve in the next sprint Team is encouraged to revise processes in order to become more effective on the following sprint Inspect how the last Sprint went in regards to people, relationships, process and tools The product owner does not attend this meeting. Start/Stop/Continue

13. Team dynamics Self-organizing teams No one person is in charge of the team’s decisions Team is responsible for committing and delivering Cross-functional teams (BSA, QA, developers, PM)

14. Backlogs Product Backlog The requirements for a system Prioritized list Includes both functional and non-functional customer requirements, as well as technical team-generated requirements. Sprint Backlog Defines the work for a sprint Represented by the set of tasks that must be completed to realize the sprint's goals

15. Burn-down chart Tracks how much value has yet to be delivered Work remaining is the Y axis and time is the X axis Sprint burn-down charts show daily progress Product burn-down chart show monthly (per sprint) progress.

16. Burn-down chart

17. Done Every sprint should produce “potentially shippable” code Team must define what “Done” means to them Everyone should have the same understanding of “Done”

18. Let’s build a website! An E-commerce website is needed for your sportswear company Product Backlog:

19. Sprint backlog Break down the tasks from the product backlog and make a commitment for the sprint: “As a user, I can view the company’s inventory”

20. Calculating Velocity

21. Burndown Chart

22. Velocity Chart

23. Quality Focus on creating “production ready” deliverables at the end of each sprint Product is designed, coded, unit tested, peer reviewed, built and QA tested during the sprint Never sacrifice quality If an item cannot be delivered, negotiate with project owner It should be apparent early in the process if something will not be delivered A sprint should always run through completion to maintain quality of code base. At the end of each spring, a decision can be made regarding the direction of the project. Lack of focus on quality reduced efficiency over time

24. Communication Sprint planning meetings allow the project owner and team to see what will be delivered and have a common “Sprint Goal” Sprint back-log is updated daily to show progress and possible estimation errors Sprint burn-down chart shows progress throughout the sprint (generated from the sprint back-log) Daily scrum meetings foster communication about daily tasks and allows the entire team to assess the project on a daily basis

25. Tools – Planning Poker Combines expert opinion, analysis to provide quick/reliable estimates Includes entire team Use special cards or modified playing card Have fun

26. Tools – Task Board Source: http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg

27. Software Tools Whiteboard Excel TFS (Scrum Templates) TeamPulse ScrumWorks Rally Software

28. Common pitfalls Mini-waterfalls in each sprint Making changes to the process before trying it out ScrumMaster behaving as a team lead Allowing sprints to go on longer than planned Bug-creep Developer-level burn-downs QA not part of the process

29. Conclusion Scrum allows for better communication Scrum helps with transparency Scrum exposes existing problems and surfaces new problems as soon as they come up Scrum helps you learn from the past