Introduction to Scrum Overview Part One Agile Requirement

Introduction to Scrum

Overview § Part One § Agile Requirement § Agile Estimation § Prerequisite for scrum § Part Two § A introduction to Scrum § Scrum Roles § Scrum Ceremonies § Scrum Artifacts § Scrum Process § Scrum Metrics § Part Three § Release planning § Scaling Scrum

To be successful in software projects, you must know all the requirements in advance! That’s not realistic. In software projects, you only really know all the requirements at the end of the project!

Agile Requirement

User Stories A user story is a brief statement of intent that describes something the system needs to do for user. Template As a <user> I want <functionality> ( so that <benefit> ) Example As a librarian I want to be able to search for books by publication year

You should also know § Themes Top level objective that may span projects and products § Epic story A large vague concept of something we want to do for a user § Spike A user story create as functional or technical spike to understand other complex / poorly understood story. Spike is used to understand those story and break the story base on that understanding

Agile Estimation

Estimation techniques § Expert opinion § Analogy § Educated guess § Disaggregating § Planning poker – Agile estimation

Planning Poker § Estimated in story points for user stories § It is most commonly used in agile software development § First described by James Grenning in 2002 and later popularized by Mike Cohn in the book “Agile Estimating and Planning” § For Eg: the deck contains the following cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. User stories are user requirements of form "As a <Some Role> I want <Some Need> so that <Some Benefit>”

Planning Poker 1. 2. 3. 4. 5. 6. 7. 8. Each person gets a deck of cards. The story to be estimated is read to all. Attendants ask clarifications for the item. Each person selects a card and puts it on the table facing down. When everyone is done, cards are exposed. If the estimations do not match a short discussion is done. Timer is started for discussion and discussion must cease when it runs out -> Goto 4. Handle next item.

We are not good in absolute measurement

We are good in comparing things

Why planning poker works ? § § § Those who do the work estimate it. Emphasizes relative estimation Estimates are within one order of magnitude. Reduces anchoring - Everyone's opinion is heard. Modeled for open discussion – forces thinking. It’s quick & fun !

Prerequisite for scrum success

Precondition for scrum success Agile Engineering § Regular refactoring (many times daily) § Frequent check ins (many times daily) § Unit Testing § Leading to Test Driven Development (TDD) § Continuous Build and Integration § Just-in-time code reviews (e. g. pair programming) Agile Testing § Early involvement § An Agile project begins when testers convert high-level requirements into testable specifications. § Work as part of the development team § The testers work with the developers to pick unit test and acceptance test frameworks, and to test the software in parallel with development. § Automate everything whenever possible § Test early, test often

Scrum picture by Kiwi Flickr

The Gurus Ken Schwaber Jeff Sutherland Mike Beedle Mike Cohn

picture by On. Task The Goal of Scrum Manage Complexity, Unpredictability and Change through Visibility, Inspection and Adaptation

The “rules” of the game Scrum in a Nutshell Scrum Master - Process Scrum Team - Deliver Product Owner - ROI Sprint 43 Sprint 44 Review Retrospective Planning Sprint 45 Review Retrospective Planning

picture by exfordy Scrum Roles

Scrum Roles § Product owner § Scrum Team § Scrum Master

Product Owner picture by Official Star Wars Blog Owner of project vision Represents the customer

The product owner plans the product in layers 23

The product owner plans the product in layers Release Product or Project How can we release value incrementally? What business objectives will the product fulfill? What subset of business objectives will each release achieve? Product Charter Elevator Pitch What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release plan Iteration What specifically will we build? (user stories) Story (Backlog Item) How will this iteration move us toward release objectives? What user or stakeholder need will the story serve? Iteration Plan How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests

The Planning Onion can grow to include product portfolios and business strategy Product or Project What business objectives will the product fulfill? Product Charter Elevator Pitch Release How can we release value incrementally? Product or Project What subset of business objectives will each release achieve? Release What user constituencies will the release serve? Iteration What general capabilities (big stories) will the release offer? Release plan Story What specifically will we build? (user stories) Story (Backlog Item) How will this iteration move us toward release objectives? What user or stakeholder need will the story serve? Iteration Plan How will it specifically look and behave? How will I determine if it’s completed? Story Details Acceptance Tests

The Planning Onion can grow to include product portfolios and business strategy Product or Project Release Iteration Story

The Planning Onion can grow to include product portfolios and business strategy Business Strategy Product Portfolio Product or Project Release Iteration Story

The Product Owner Is a: §Subject Matter Expert § § Understand the domain well enough to envision a product Answer technical questions on the domain for those creating the product §End User Advocate § Describe the product with understanding of users and use, and a product that best serves both §Customer Advocate § Understand the needs of the business buying the product and select a mix of features valuable to the customer Business Advocate § Understand the needs of the organization paying for the software’s construction and select a mix of features that serve their goals Communicator § Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time Decision Maker § Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions

• Communicate Business Goals, Customer Goals, End User Goals • Coordinate involvement of SMEs, users, and business stakeholders • Coordinate with other product owners to insure coherence of product and releases Product Owner Responsibilities Participate daily Evaluate product at end of Sprint and add or remove stories from backlog as necessary Be available to answer questions and clarify details on user stories Verify stories are done based on acceptance criteria Create and maintain the product backlog Organize the backlog into incremental releases 29 Specify objective acceptance criteria for stories

Scrum Team picture by ewen and donabel Small (5– 9 people) Colocated - Cross-functional Self-organized - Full-time

The Team Define tasks Estimate effort Develop product Ensure quality Evolve processes

Scrum Master Servant leader Team protector Troubleshooter Scrum guide picture by Orange Beard

Scrum Master Remove impediments Prevent interruptions Facilitate the team Support the process Manage management

Pigs and Chickens Product Owner Scrum Master Team Members Users Managers Marketing

What about manager’s role in scrum?

Manager’s role (If it’s nobody else. . Its you!) § Buy snacks § Handle resource conflict § Strategic release planning § Salary negotiation § § § § Recruitment Clean the office Coach the scrum masters Technology evangelist Synchronize multiple team Solve high level impediments Chief product owner

Scrum Ceremonies

Ceremonies § § Sprint Planning Meeting #1 Sprint Planning Meeting #2 Daily Standup Retrospective

Sprint Planning Team capacity, Product backlog, Current product, Business, Technologies + Goal = picture by Darcy Mc. Carty

Sprint Planning Face-to-face communication Small reversible steps User’s perspective

Sprint Planning (Part 1) Strategical level planning Prioritize/select features Discuss acceptance criteria Verify understanding ½ - 1 hour per sprint/week

Sprint Planning (Part 2) Tactical level planning Define sprint backlog items Estimate sprint backlog items Use velocity (Yesterday’s Weather) Share commitment ½ - 1 hour per sprint/week

Daily Scrum The heartbeat of Scrum picture by Hamed Saber

Daily Scrum Commitment and accountability Say what you do, do what you say Whole world is invited picture by Hamed Saber

Daily Scrum What I did since last meeting What I will do until next meeting What things are in my way Only the team talks Not to Scrum Master No problem solving Max 15 minutes Standing up

Sprint Task Board picture by Mountain Goat Software

Definition of Done Avoid the 90% syndrome Coded, commented, checked in, integrated, reviewed, unit tested, deployed to test environment, passed user acceptance test & documented. . . = DONE

Sprint Review Satisfy Product Owner Get feedback on product picture by oskay

Sprint Review Informal, no slides Whole team participates The world is invited picture by oskay

Sprint Review Preparation needed Show complete features Accept or reject results 1 -2 hours per sprint/week

Sprint Retrospective Evolve the process picture by kevindooley

Sprint Retrospective Reflect on process and product Whole team participates

Sprint Retrospective What to start doing What to stop doing What to continue doing (Product Owner not required)

Scrum Artifacts

Scrum Artifacts § Product Backlog § Sprint Burndown chart

Product Backlog Express value Defer decisions picture by juhansonin

Product Backlog sample from Eclipse. org

Product Backlog Owned by Product Owner High-level requirements Expressed as business value Not complete, nor perfect Expected to change & evolve Limited view into the future

Product Backlog Includes rough estimates Prioritized by value & risk Better to describe as user stories Publicly visible

Sprint Backlog Breakdown of business value into assignable tasks picture by oskay

Sprint Backlog

Sprint Backlog Owned by the team Team allocates work No additions by others

Sprint Burn Down picture by Nibiru. Tech

Scrum Metrics

Velocity § How many points can the team complete in one iteration. § Easy to measure. § Fixes estimation errors. § Easily reflects the project status. § Primary parameter in planning.

Putting Velocity to Work: Burn Charts Burn-down chart How much work remains to be completed? Burn-up chart How much work has been completed? Combined burn chart How much work has been completed and how much work remains? Copyright © 2007 -2009 Dave Nicolette

Burn Down Chart Scope change

Burn Up Chart Scope keeps expanding Pipeline gets fatter

Scrum process

SCRUM PROCESS Scrum. Master Input from End-Users, Customers, Team and Other Stakeholders Daily Scrum Meeting and Artifacts Update Product Backlog Refinement Sprint 4 days, with Product Owner 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 4 5 6 7 Feature A A Feature B B Feature C C Feature D D Feature E E Feature F F Feature G G Feature H Feature I Feature J Feature K Team Selects How Much To Commit To Do By Sprint’s End Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12 Task 13 Task 14 Sprint Planning Sprint Backlog Meeting 4 Weeks 5 mins each day to work No Changes in Duration or Goal Review Potentially Shippable Product Increment Feature L Feature M Product Backlog Retrospective

SCRUM PROCESS Scrum. Master Input from End-Users, Customers, Team and Other Stakeholders Daily Scrum Meeting and Artifacts Update Product Backlog Refinement Sprint Product Owner 1 2 3 4 5 6 7 8 9 10 11 12 13 Feature A Feature B Feature C Feature D Feature E Feature F Feature G Feature H Feature I Feature J Feature K 4 weeks or less Team Selects How Much To Commit To Do By Sprint’s End Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12 Task 13 Task 14 Sprint Planning Sprint Backlog Meeting No Changes in Duration or Goal Review Potentially Shippable Product Increment Feature L Feature M Product Backlog Retrospective

Rules of scrum § § § § Obtain number of hours commitment upfront Gather requirements/estimates up front Enter time daily Daily Builds No new requirement for a sprint Keep daily standup meeting short Code inspection are paramount

Release Planning

Scrum Implementation Steps § Get your backlog organized § Estimate your product backlog § Sprint planning (Requirements) § Sprint planning (Tasks) § Create a collaborative work space § Sprint! § Daily Standup and counted § Track progress with daily burn down chart § Sprint review § Sprint Retrospect Development Start Scrum Kickoff Release Date Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 (brief, e. g. 3 -5 Days) Time

Release Planning Plan features in sprints and releases Releases depend on accepted sprints picture by Sviluppo Agile

How to calculate time? Time (in no of iterations) = ( No of Story points / Velocity of each sprint/iteration)

Release Sprints Usability testing Documentation Help files Packaging pictures by Vista. ICO

Scaling Scrum

Scaling Scrum 50 People (Analysts, Designers, Coders, Testers, Technical Writers, etc. )

Scaling Scrum Team A Team B Team C Team D Team E

Scaling Scrum Team A Team B Team C Team D Team E Cross-Functional (Designers, Coders, Testers, etc. ) (Designers, Coders, Testers, etc. )

Scaling Scrum Team A Team B Team C Team D Team E

Scaling Scrum Team A Team B Team C Team D Team E

Scaling Scrum Product Owner Team A Team B Team C Team D Team E

Scaling Scrum Chief Product Owner PO Team A PO Team B Team C PO Team D Team E

During the Sprint Team A Team B Team C Team D Team E

During the Sprint Team A Team B Team C Team D Team E

During the Sprint Scrum of Scrums Daily Meeting of Team Representatives Coordination, Dependencies Mgt, Block Surfacing Team A Team B Team C Team D Team E

Scrum Tools § For successful self-organization, with maximum clarity and visibility, Team should use information radiators § Physical task board § Physical user story cards § Paper Sprint Backlog and Burndown Chart § Electronic Scrum Management Tools § Version. One, Scrum. Works, etc. § If needed, use them for release planning and management only § For the Team’s self-management during the Sprint, using information radiators will produce much better results, with less effort, cost and hassle

Moving Forward… § Scrum is simple – but difficult § An understanding and appreciation of Agile values and principles is essential § Scrum alone will not create better products. § Engineering, design and testing practices need to become more Agile § Interactions and communication need to become clearer, more personal and more transparent § Honesty, trust and a sense of commitment need to be developed § When the going gets tough it is easy to slip back into the old way of doing things. Courage is essential. © 2006, Tobias Mayer/Agile Thinking - http: //agilethinking. net

Agile/Scrum Resources § Web Sites § § www. agilemanifesto. org www. scrumalliance. org www. controlchaos. com www. mountaingoatsoftware. com § Recommended Books § Agile Project Management with Scrum § Ken Schwaber § Agile Estimating and Planning § Mike Cohn © 2006, Tobias Mayer/Agile Thinking - http: //agilethinking. net

Questions?