280 likes | 530 Views
Introduction to Scrum. Jeremy Neuharth Applications Manager, State Bank & Trust. Brief History of Scrum. “Co-created/Ideas” in 1986 by Hirotaka Takeuchi Ikujiro Nonaka Started to be used in early 1990’s Formalized as Scrum in 1995 by Ken Schwaber Jeff Sutherland
E N D
Introduction to Scrum Jeremy Neuharth Applications Manager, State Bank & Trust
Brief History of Scrum • “Co-created/Ideas” in 1986 by • Hirotaka Takeuchi • IkujiroNonaka • Started to be used in early 1990’s • Formalized as Scrum in 1995 by • Ken Schwaber • Jeff Sutherland • First to actually call the process Scrum • Other Major Players • Mike Beedle • Mike Cohn
Basic Principles • Self-organizing teams • Focus on communication via co-location and daily Scrums • “Customers” will (want or need) change their mind • Requirements Churn • Use an empirical approach • A problem cannot be fully understood or defined • Focus on maximizing the team's ability to deliver quickly and respond to emerging requirements. • Short development/execution cycles • Bring (business) value to the customer in a potentially shippable product each “sprint”
Sprint Goal Gift Wrap Gift Wrap Coupons Coupons Cancel Return Cancel Sprint Backlog 24 hours Sprint 2-4 weeks Return Potentially Shippable Product Increment Scrum @ 50,000 Feet Change Product Backlog
What is a Sprint? • An “iteration” • Scrum projects make progress via a series of “sprints” • Typical duration is 2–4 weeks • A calendar month at most • A constant duration leads to a better rhythm/productivity • Commit to as long as you can keep change out of it • Protected from Change • If the business needs to re-align priorities the sprint is stopped and a new one is created with new product backlog priorities • During the Sprint the Product is • Designed • Coded • Tested • Documented • Etc
Roles: Product Owner • Define the features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results • Owner of the Product Backlog
Roles: ScrumMaster • Represents management to the project • Responsible for enacting Scrum values and practices • Removes impediments /blockers • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences
Roles: Team • Typically 5-9 people • Cross-functional: • Programmers, testers, business analysts,technical writers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator) • Teams are self-organizing • Ideally, no titles but rarely a possibility • Membership should change only between sprints
Team Capacity Ceremony: Sprint Planning • Product Backlog • Sprint Prioritization • Business Conditions • Analyze and evaluate product backlog • Select sprint goal • Current Product • Technology • Sprint goal • Sprint Planning • Sprint Planning Meeting • Decide how to achieve sprint goal (design) • Create sprint backlog (tasks) from product backlog items (user stories/features) • Estimate sprint backlog in hours • Spring backlog
Ceremony: Sprint Planning • Team selects items from the product backlog they can commit to completing • Sprint backlog is created • Tasks are identified and each is estimated (1-20 hours) • Collaboratively, not done alone by the ScrumMaster • High-level design is considered • As a customer, I should be able to return product via the order page on the website. • Code the middle tier (8) • Code the user interface (4) • Write test fixtures (4) • Code the foo class (6) • Update performance tests (4) • Project Backlog • Sprint Backlog
Ceremony: Daily Scrum • Parameters • Daily • 15-minutes • Not for problem solving • Whole world is invited • Only team members, ScrumMaster, product owner, can talk • Helps avoid other unnecessary meetings • Answer three questions to stimulate discussion
Ceremony: Daily Scrum (Questions) • NOTE: These are not status for the ScrumMaster • They are commitments in front of peers
Ceremony: Sprint Review • Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal • 2-hour prep time rule • No slides • Whole team participates • Invite the world
Ceremony: Sprint Retrospective • Periodically take a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates • ScrumMaster • Product owner • Team • Possibly customers and others
Artifacts: Product Backlog • The requirements • A list of all desired work on the project • Ideally expressed such that each item has value to the users or customers of the product • Business Value • User Stories • Prioritized by the product owner • At minimum reprioritized at the start of each sprint • Can be reprioritized at any time
Artifacts: Sprint Backlog • Individuals sign up for work of their own choosing • Work is never assigned • Estimated work remaining is updated daily • Any team member can add, delete or change the sprint backlog • Work for the sprint emerges • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining as more becomes known
Sprint Goal Gift Wrap Gift Wrap Coupons Coupons Cancel Return Cancel Sprint Backlog 24 hours Sprint 2-4 weeks Return Potentially Shippable Product Increment Quick Review: Putting it All Together Change Product Backlog
Jeremy Neuharth, CSM • Applications Manager, State Bank & Trust • Work • 701.298.7177 • jneuharth@statebanks.com • Home • 701.388.9063 • jeremy@neuharth.net Questions, comments, or discussion. Portions of this presentation provided by: Mountain Goat Software, LLC