• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scrum overview

Scrum overview



Overview of SCRUM development process. I put this together to present to my company/group.

Overview of SCRUM development process. I put this together to present to my company/group.

Most slides are "borrowed" from Alan Shalloway's presentation.



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Scrum overview Scrum overview Presentation Transcript

    • Scrum Overview Rob Bastian The definition of insanity is doing the same thing over and over and expecting different results. Benjamin Franklin
    • Scrum Key Takeaways
      • Self directed, self organizing cross functional team
      • Planning driven by customer prioritization
      • Time boxed iterations
      • Daily stand up meeting
      • Demo at end of each iteration
    • What is Scrum anyway?
      • Scrum is a process for developing products such as software and quickly getting the products to the customer.
      • Iterative and incremental development method
      • Emphasis on empirical process management rather than defined process
        • Empirical means “ Originating in or based on observations and modifications ”
      • CMM Level/3 and ISO 9001 compliant
    • Royce: The Waterfall Model
      • In 1970, Dr. Winston Royce published “Managing the development of large Software Systems”
      System Req. Software Req. Analysis Program Design Coding Testing “ I believe in this concept, but The implementation described above is Risky and invites failure ”
    • Royce: The Waterfall Model
      • On the next page showed the following:
      System Req. Software Req. Analysis Program Design Coding Testing “ Hopefully, the iterative interaction between The various phases is confined to Successive steps
    • Waterfall is a powerful attractor
      • For Management
        • It is a “defined process” – thus “feels right”
        • It gives the illusion of control
          • Of time
          • Of people
          • Of money
        • Allows for “hands off” management
      • For Developers
        • It’s just “following a recipe”
        • Left alone for long periods of time
    • Why is Waterfall less than optimal?
      • Built on the assumption that we can figure out what we need to do ahead of time and then plan accordingly
      • Building software is about solving problems and not all problems can be anticipated so the ability to constantly change course in the face of issues is critical
        • “ No no no, I'm going to leave them alone and not actually witness them dying, I'm just gonna assume it all went to plan. What? “ – Dr. Evil
    • Why is Waterfall less than optimal?
      • One study showed that typical requirements specifications are 15% complete and only 7% correct and that it was not cost effective to complete or correct them
      • Evidence/data indicates that more detailed up-front requirements not only does NOT help much in preventing requirements change, but in fact makes requirements change MORE likely (because many of the details you tried to "guess" up-front we're wrong and have to be changed)
    • Why is Waterfall less than optimal?
      • We can’t really know what we need until we see a little of what we have
        • Customers change their minds
        • Developers see new possibilities
        • New function often require new designs
      • Building an architecture up front assumes:
        • You know what you really need
        • You don’t overbuild it
        • People will follow it
        • It anticipates all needs and doesn’t need to change – that is architectures are often built to be filled out, not to evolve as needs change
    • Why is Waterfall less than optimal?
      • Features aren’t prioritized
        • Why prioritize features if they’ll all be implemented?
        • Developers potentially work on least important features first
        • Most important features may not get done
      • Testing always gets impacted
        • The reality is the delivery dates are hard to move
        • Engineering tasks that take longer than anticipated will “steal” time from the QA team
        • “ Stealing” from QA costs more later…
    • How is Scrum different?
      • Planning and Prioritization
      • Iterations, Increments and Features
      • Refactoring and Emergence
      • Self-organized and Cross Functional Collaboration
    • How is Scrum different? Planning and Prioritization.
      • Planning
        • Scrum team meets with stakeholders at the beginning of an iteration to plan what work will be taken on during the iteration
        • Scrum team meets every day for 15 minutes to plan daily work
      • Prioritization
        • Stakeholders prioritize features so we know we’re working on most important features first
    • How is Scrum different? Iterations, Increments and Features
      • Feature driven
        • Scrum teams focus on building vertical slices of an application feature by feature
        • Three/four levels of “done”
      • Time boxed
        • Team works in iterations
        • Team decides how much work will “fit” into the iteration
        • At the end of an iteration a increment of working functionality is delivered
        • At the end of an iteration the team demonstrates what it built to stakeholders
    • How is Scrum different? Refactoring and Emergence.
      • No big up front design
        • Architecture/infrastructure emerges as features are completed and refactoring is done
        • Refactoring MUST be done as features are implemented or you’ll be toast
      • You Aren’t Going to Need It (YAGNI)
        • It’s better to let the features drive the architecture as they are developed than to attempt to build it all up front
    • How is Scrum different – Self organized and cross functional collaboration
      • Self Organization
        • Team should decide how best to accomplish the goal of the iteration
      • Team Swarm
        • Entire team can “swarm” on an issue or task until it’s complete – e.g. writing acceptance tests
      • Cross Functional
        • Anyone should be able to contribute to any task (within reason)
    • Scrum Process
      • Sprint Planning Meeting
      • Sprint
      • Daily 15 minute meeting (Scrum meeting)
      • Sprint Review
      • Retrospective
    • Sprint Planning Meeting
      • Part I – Establish a Sprint Goal
        • Product owner prioritizes work for team for the next Sprint (iteration) and works with team to determine how much work will “fit” into next Sprint
        • Work is defined in the Product Backlog document that contains all known and outstanding enhancements and non-critical bugs
        • Product owner is ensured that only highest priority work is being done
      • Part II – Task Breakdown and Estimation
        • Team breaks down product backlog items into work or tasks no more than 16 hours in length
        • Tasks include QA tasks, unit and rtests, platform processes like design documentations and code reviews
        • If tasks cannot be identified because not enough investigation is done then investigation tasks are tracked to determine approach
    • Example Product Backlog
    • Sprint
      • Fixed length iteration. Recommendation is 30 calendar days
      • Team and Customer agree on what work can be completed during Sprint and define a goal
      • Team self organizes to do work
      • Team conforms to standards and procedures
      • Team only works on tasks directly related to completing sprint goals
    • The Daily Scrum Meeting
      • Attended by developers, testers, analysts, customers and Scrum master
      • Normally standing meeting to encourage brevity. 15-20 minutes
      • No other discussion beyond the 3 questions
        • What did you do since we last met?
        • What are you going to work on next?
        • Is there anything impeding your progress?
      • Scrum master tracks and resolves issues
      • What does “done” mean
    • Example Sprint Backlog and Burn Down Chart
    • Sprint Review Meeting
      • Empirical observation by management and stakeholders on progress of the project
      • The scrum teams shows accomplishments during the sprint
        • Demo
        • Informal
      • All stake holders are invited
      • Project assessed against sprint goals
      • Maintains trust by not hiding undone work
      • Functionality
    • A Metric Leading to Agility
      • Running Tested Features
        • The desired software is broken down into named features (requirements, stories) which are part of what it means to deliver the desired system.
        • For each named feature, there are one or more automated acceptance tests which, when they work, will show that the feature in question is implemented.
        • The RTF metric shows, at every moment in the project, how many features are passing all their acceptance tests.
    • A Metric Leading to Agility (cont)
    • Retrospective
      • Scrum team and customer attends
      • Process improvement at the end of every sprint
      • What went well, what can be improved
      • What does management need from us
      • Team devices solution to most vexing problems
    • Appendix
    • Scrum Flow
    • How we normally deliver functionality What we know to start Functionality / Problem solved Effort expended (design, coding, etc)
    • Tracer Bullets
      • A single piece of functionality is developed within the overall system structure and the development environment. This functionality works from the user interface, through all intermediate levels to the persistent data stores and back. This “tracer bullet” demonstrates that the development environment and operation environment work, allowing the team and users to refine their aim in future iterations 1 .
      1 Andy Hunt and Dave Thomas (The Pragmatic Programmer)
    • Up Front Requirements
      • Evidence indicates that no matter how detailed you try to flesh-out the requirements "up front", it still wont prevent more details from being discovered, and that you couldn’t have known them earlier before delving into design/implementation details
    • Ready, Fire, Aim, Aim, Aim…
      • *Ready, Fire, Aim
      • * Ready…Aim… Aim… Aim… Aim… Fire… Aim, aim, aim, aim…