Your SlideShare is downloading. ×
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum

2,534

Published on

A presentation of Scrum basics.

A presentation of Scrum basics.

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

  • Be the first to like this

No Downloads
Views
Total Views
2,534
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
44
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scrum…getting software done
  • 2. What is Scrum? An Agile framework for completing complex projects – Simple concepts, difficult to implement Practices Principles Values
  • 3. How Scrum Helps IT systems + abstract ideas + requirements + PEOPLE = craziness! – Many pieces of unreliable and complex systems – No tangible products or measurable designs – Requirements…. • Not fully known • Frequently changing • Hard to articulate • Many stakeholders – People…we’re just nuts Requirements Technology Graph: http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm
  • 4. How Scrum Helps • Defined processes, like waterfall, don’t handle complexity well Traditionally we: – Define the requirements up front – Break down the work – Estimate effort/duration – Plan out the work – And then we begin to build – But don’t change the plan! This • then That • then This • then
  • 5. How Scrum Helps • Empirical processes account for complexity – Visibility: aspects of the process that affect the outcome must be visible, and correct. – Inspection: aspects of the process must be inspected frequently enough to detect unacceptable variance – Adaptation: if through inspection, it is found there is unacceptable variance then the process must be changed as quickly as possible to minimize further deviation • Scrum uses a short iterative cycle to verify everything is going like we had hoped
  • 6. SCRUMMY VALUES & PRINCIPLES The ideas that guide a Scrum implementation
  • 7. Agile Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/
  • 8. Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • 9. Scrum Values • Commitment and Focus • Openness • Respect • Courage http://www.scrumalliance.org/pages/code_of_ethics
  • 10. Commitment and Focus • Commitment is our willingness to dedicate ourselves to a goal and to do our best to meet that goal. • Focus means that we concentrate on and are answerable for doing the things that we have committed ourselves to do, rather than allowing ourselves to become distracted or diverted. As practitioners in the global Scrum community: – We take responsibility for and fulfill the commitments that we undertake – we do what we say we will do. – We make decisions and take actions based on the best interests of society, public safety, and the environment. – When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or omissions caused by others, we promptly communicate them to the appropriate individual or body. We accept accountability for any issues resulting from our errors or omissions and any resulting consequences. – We protect proprietary or confidential information that has been entrusted to us. – We proactively and fully disclose any real or potential conflicts of interest to the appropriate parties. http://www.scrumalliance.org/pages/code_of_ethics
  • 11. Openness • Openness: affording unobstructed entrance and exit; not shut or closed.; Carried on in full view;* As practitioners in the global Scrum community: – We earnestly seek to understand the truth. – We strive to create an environment in which others feel safe to tell the truth. – We are truthful in our communications and in our conduct. – We demonstrate transparency in our decision-making process. – We provide accurate information in a highly visible and timely manner. – We make commitments and promises, implied or explicit, in good faith. – We do not engage in or condone behavior that is designed to deceive others. http://www.scrumalliance.org/pages/code_of_ethics * http://www.thefreedictionary.com/openness
  • 12. Respect • Respect means that we show a high regard for ourselves, others, and the resources entrusted to us. Resources entrusted to us may include people, money, reputation, the safety of others, and natural or environmental resources. • An environment of respect engenders trust, confidence, and performance excellence by fostering mutual cooperation and collaboration — an environment where diverse perspectives and views are encouraged and valued. As practitioners in the global Scrum community: – We respect the rights and beliefs of others. – We listen to others’ points of view, seeking to understand them. – We approach directly those persons with whom we have a conflict or disagreement. – We conduct ourselves in a professional manner, even when it is not reciprocated. – We negotiate in good faith. – We do not exercise the power of our expertise or position to influence inappropriately the decisions or actions of others in order to benefit personally at their expense. – We do not discriminate against others based on, but not limited to, gender, race, age, religion, disability, nationality, or sexual orientation. – We do not engage in any illegal behavior. http://www.scrumalliance.org/pages/code_of_ethics
  • 13. Courage • Courage means that we have the daring to do the best that we can and the endurance not to give up. We have the determination and resolution to take ownership of the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result. As practitioners in the global Scrum community: – We share bad news even when it may be poorly received. – We avoid burying information or shifting blame to others when outcomes are negative. – We avoid taking credit for the achievements of others when outcomes are positive. – We would rather say, “no,” than make false promises. – We accept the possibility of failure but also know that we can learn from failure and apply those learnings to our next attempt. – We acknowledge that change is inevitable, that change leads to growth, and that growth guides us toward improvement. – We admit when we need help and we ask for help. http://www.scrumalliance.org/pages/code_of_ethics
  • 14. How can we better adopt these values and principles? • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • Commitment and Focus • Openness • Respect • Courage 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • 15. SCRUMMY ROLES The people in Scrum
  • 16. The people in Scrum • The Team – Self-organizes to get the work done • Product Owner – Responsible for the business value of the project • ScrumMaster – Ensures the team is functional and productive
  • 17. The Team • Is cross-functional • Is right-sized (the ideal size is seven -- plus/minus two -- members) • Selects the sprint goal and specifies work results • Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal • Organizes itself and its work • Demos work results to the product owner and any other interested parties. http://www.scrumalliance.org/pages/scrum_roles
  • 18. The Team • Cross Functional – Different specialties • Developers • Testers • Tech writers • Usability engineers • Architects • Designers • Analysts • Any one needed to complete the sprint! – Fuzzy role boundaries – Common goal – Each member is held accountable to reach the goal
  • 19. The Team: A Lacrosse Story
  • 20. The Team: A Lacrosse Story
  • 21. The Team • Self-organizing – Pulls in work – Plans their own work – Cooperative development and decision making – Authority to do what is needed to reach the sprint goal – Self inspecting
  • 22. Product Owner • Decides what will be built and in which order • Defines the features of the product or desired outcome of the project • Chooses release date and content • Ensures profitability(ROI) • Prioritizes features and outcomes according to market value • Adjusts features/outcomes and priority as needed • Accepts or rejects work results • Facilitates sprint planning ceremony • "single wringable neck" http://www.scrumalliance.org/pages/scrum_roles
  • 23. Product Owner • What makes a great Product Owner? http://agilescout.com/infographic-what-is-a-product-owner- responsible-for/
  • 24. Product Owner • What makes a great Product Owner? – Visionary – Open to negotiation – Available within reason – Informed about product – Communicative http://agilescout.com/top-10-essential-product-owner-characteristics/
  • 25. Product Owner • Answers 4 questions: 1. Why are we building this, and what problem are we solving? 2. Who is it for: Primary Audience? Secondary? 3. What is important to that audience? 4. What are the constraints? http://agilescout.com/agile-product-management-product-owners- are-key/
  • 26. ScrumMaster • Ensures that the team is fully functional and productive • Enables close cooperation across all roles and functions • Removes barriers • Shields the team from external interferences • Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning • Facilitates the daily scrums http://www.scrumalliance.org/pages/scrum_roles
  • 27. ScrumMaster • The goals – Increase collaboration between the team and product owner – Remove impediments inside the organization – Help the team reach their potential
  • 28. ScrumMaster • The goals – Increase collaboration between the team and product owner – Remove impediments inside the organization – Help the team reach their potential • The obstacles – Waterfall development – Command and control – Breaking down barriers between departments – Skeletons in the closet
  • 29. ScrumMaster • Some ScrumMaster traps – Responsible for product delivery
  • 30. ScrumMaster • Some ScrumMaster traps – Responsible for product delivery – Becoming a manager
  • 31. ScrumMaster • Some ScrumMaster traps – Responsible for product delivery – Becoming a manager – Making team decisions
  • 32. SCRUMMY ARTIFACTS The deliverables
  • 33. Artifacts • Product Backlog – list of items to be done • Sprint Backlog – items to be done in this sprint • Product Increment – shippable product Also, the burn down charts
  • 34. Product Backlog • Product Owner owns and prioritizes • Anyone can add to it • If it isn’t in the product backlog, it doesn’t exist
  • 35. Product Backlog • Is software ever “correct” the first release? – More requirements will emerge as the product is built…it’s what is expected and wanted – Customer feedback and changes are reflected in backlog • Invest time and money only in high-priority features – 80% of value from 20% of features
  • 36. Product Backlog
  • 37. Product Backlog Items • Just enough detail to complete the item in one sprint – Might contain • business processes • Data needed • Designs • Items further in the future can be larger and more vague • Item descriptions should be as brief as possible – User stories!
  • 38. User Stories • Three C’s – Card : User stories are written on cards. The card does not contain all the information that makes up the requirement. – Conversation: The requirement itself is communicated from customer to programmers through conversation: an exchange of thoughts, opinions, and feelings. Usually over a period of time. – Confirmation: At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they’ve done what is needed. http://xprogramming.com/articles/expcardconversationconfirmation/
  • 39. User Stories • Describes a feature from a user’s perspective As a user I want to filter my search results by order # so that I don’t have to scroll through all the results
  • 40. User Stories • I ndependent – schedule and implement in any order • N egotiable - co-created by the customer and programmer • V aluable - valuable to the customer • E stimable - can be estimated • S mall – easy to know what's in the story's scope • T estable - I understand what I want well enough that I could write a test for it http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  • 41. User Stories • Acceptance Criteria – Product owner defines acceptance criteria before sprint planning – During sprint planning acceptance criteria are discussed and negotiated – Should be short and easy to understand As a user I want to filter my search results by order # so that I don’t have to scroll through all the results Acceptance Criteria: Entering a order # should only show orders with that order #.
  • 42. When is a Story Done? • Definition of Done – Applies to all stories – States the deliverables for each story (code, etc) DoD Helps to build the thing right (quality) Acceptance Criteria Helps to build the right thing (functionality) vs
  • 43. Definition of Done http://www.scrumalliance.org/articles/107-how-do-we-know-when- we-are-done
  • 44. Sprint Backlog • The team commits to a certain number of stories during Sprint Planning • Each Story also contains technical tasks to build it http://www.mountaingoatsoftware.com/scrum/sprint-backlog
  • 45. Reporting Progress • Task Board – Electronic vs Wall
  • 46. Reporting Progress Burndown Burnup
  • 47. Product Increment • The product with the new functionality built during the sprint • New features are “done” • Potentially shippable “Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable...the increment must be a complete slice of the product. It must be “done.” Each increment should be additive to all prior increments and thoroughly tested, ensuring that all increments work together.” Scrum Guide: http://www.scrum.org/scrumguideenglish/
  • 48. SCRUMMY CEREMONIES Aka Meetings
  • 49. Ceremonies • Sprint Planning – Plan the next iteration • Daily Scrum – Collaborate with team members • Sprint Reviews – Show off what was built • Sprint Retrospectives – What went well? what did not go well?
  • 50. Sprint Planning • Who Participates? – The team – Product Owner – Customers and Management • Inputs – Product Backlog – Team capabilities – Business Conditions – Definition of Done – Technology – Current Product – Velocity Sprint Backlog • Detailed tasks • Priorities • Detailed Estimates
  • 51. Daily Scrum • Who participates? – The team • Each team member answers 3 questions – What did you do yesterday? – What are you doing today? – What is getting in your way? • It is not a status report to anyone • It is a way to collaborate with team members • Timeboxed to 15 minutes
  • 52. Scrum of Scrums • Some suggestions from Mike Cohn – A designated rep from each team attends – Timeboxed 15min for daily meetings • Leave time after for resolving problems – Problems that arise should be addressed and fixed – Suggested Questions: 1. What has your team done since we last met? 2. What will your team do before we meet again? 3. Is anything slowing your team down or getting in their way? 4. Are you about to put something in another team’s way? – No names are used in reporting…speeds things up http://www.scrumalliance.org/articles/46-advice-on-conducting-the- scrum-of-scrums-meeting
  • 53. Sprint Review • Who participates? – The team – ScrumMaster – Product Owner, Customers – Stakeholders and other interested parties • Team presents what it is has accomplished – Demo or fair style • Verify “done” with customers/product owner • Don’t hide undone work
  • 54. Sprint Review w/ Multiple Projects and Teams • Demo format – Planned agenda so customers can come and go to see their product • Fair format – Teams set up booths that customers can interact with the product
  • 55. Sprint Retrospective • Who participates? – The team – The ScrumMaster facilitates • An open environment is needed – Means no managers or product owners • What went well, what didn’t – Improvements prioritized – Team devises solutions
  • 56. Review • Agile and Scrum Values and Principles – Individuals and interactions over processes and tools, Completed functionality over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan – Commitment, Focus, Openness, Respect, Courage • 3 Roles – Product Owner, Scrum Master, The Team • 4 Ceremonies – Sprint planning, Daily scrum, Sprint review, Sprint retrospective • 3 Artifacts – Product backlog, Spring backlog, Product increment
  • 57. Where to now?

×