! Introduction to Scrum The Waterfall model!
advertisement
Introduction to Scrum! September 1, 2011! ! David Broman! Department of Computer and Information Science! Linköping University, Sweden! davbr@ida.liu.se! 2 The Waterfall model! ! ! Requirements David Broman davbr@ida.liu.se! One of the first life-cycle models (Royce, 1970)! Very common, very criticized! System Design Program Design Finish each phase before continue to next.! Why is the waterfall model ! so criticized? ! Implementation Which are the problems?! Can it be useful sometimes?! Integration Testing System Testing Milestone and deliverable at ! Acceptance Test each step. (Artifacts such as Design document, Req. Specification. etc.).! Maintenance ! Time ! Part I! Processes and models in Software Engineering! Part II! SCRUM! The Waterfall model - some arguments! 3 David Broman davbr@ida.liu.se! Pros! ! Simple, manageable and easy to understand ! ! Fits to common project management practices (milestones, deliverables etc.)! ! Focus on requirements and design at beginning, save money and time at the end ! ! Can be suitable for short projects (some weeks)! ! Can be suitable for "stable" projects, where requirements do not change! ! Focus on documents, saves knowledge which can be reused by other people.! ! Widely used, e.g. US Department of Defense! ! Can be suitable for fixed-price contracts ! ! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! The Waterfall model - some arguments! Cons! ! Software requirements change, hard to sign-off on a SRS.! ! Early commitment. Changes at the end, large impact.! ! Feedback is needed to understand a phase. E.g. implementation is needed to understand some design.! ! Difficult to estimate time and cost for the phases.! ! Handling risks are not part of the model. Pushes the risks forward.! ! Software "is not" developed in such a way. It evolves when problems are more understood. Little room for problem solving.! ! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 4 David Broman davbr@ida.liu.se! 5 Can we improve the model?! David Broman davbr@ida.liu.se! Iteration back to previous phase! ! Requirements System Design Program Design Implementation Integration Testing System Testing Acceptance Test Danger! E.g. a performance problem can result in a major requirements change. Very expensive rollback...! Part II! ! ! Part I! Processes and models in Software Engineering! Maintenance SCRUM! 6 Do it twice?! David Broman davbr@ida.liu.se! Second round, do it right.! ! Requirements The original paper is actually! misunderstood! ! System Design (Royce, 1970) includes! ! Iteration of phases! ! "Do it twice" prototype! Program Design First round, a prototype! ! Implementation Integration Testing System Testing Acceptance Test ! Part I! Processes and models in Software Engineering! Input to the phases in the second round ! ! Part II! SCRUM! Maintenance 7 Is overlapping phases a solution?! David Broman davbr@ida.liu.se! When do we "sign-off", ! e.g. when do we have all requirements?! ! What if a major design flaw is discovered at the testing phase?! ! requirements! design! Release!! implementation! test! Time! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 8 Is overlapping phases a solution?! David Broman davbr@ida.liu.se! What kind of structure have we actually achieved? No sign-off. How does this help us?! ! requirements! design! Release!! implementation! test! deployment! Time! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 9 What should be built?! David Broman davbr@ida.liu.se! The hardest single part of building a software system is deciding precisely what to build ! (Frederick P. Brooks)! ! How? By delivering several releases?! ! design! Release!! implementation! test! deployment! Time! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 10 Iterative Development! When should the releases take place?! Time-boxing - The time period is fixed for each iteration. ! ! Customer Feedback! David Broman davbr@ida.liu.se! What should be included in the release?! Prioritized functionality - Do the most important parts first.! Customer Feedback! R1! R2! design! implementation! Iteration 1! Iteration 2! test! Iteration 3! deployment! Time! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Final Release!! 11 We are using an iterative process!! Define a plan with 1..N iterations. We do not have to care about plans... ! Now, let's hack! ! David Broman davbr@ida.liu.se! Harry! the hacker! Time! Is this a good iterative process?! ! Of course not. We need some structure!! ! Methodologies and defined Process frameworks ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Agile Approaches - Agile Alliance ! 12 David Broman davbr@ida.liu.se! Lightweight approaches to satisfy the customers with ! "early and continuous delivery of valuable software"! Manifesto for Agile Software development! Favor! ! Individuals and interactions over processes and tools! ! Working software over comprehensive documentation! ! Customer collaboration over contract negotiation! ! Responding to change over following a plan! ! (http://agilemanifesto.org, 2001)! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 13 Scrum! David Broman davbr@ida.liu.se! Approach public in 1995 at OOPSLA! "Scrum" strategy used in rugby for getting! an out-of-play ball back into play.! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 14 Intro! ! Part I! Processes and models in Software Engineering! David Broman davbr@ida.liu.se! Part II! SCRUM! 15 Scrum Overview! David Broman davbr@ida.liu.se! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 16 The Sprint (1)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list David Broman davbr@ida.liu.se! • An iteration • Time-boxed • 30 days or less • No time between sprints Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective • 40 hours week • Open and visible Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 17 The Team! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list David Broman davbr@ida.liu.se! • Cross functional • No titles • Self-organized • 7 plus/minus two • Develops, tests, documents etc. in iterations = sprints Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 18 Product Owner! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • One and only one person • Prioritize and manage the product backlog • Manage ROI • The customer ”interface” The product owner may not • act as a project manager • tell when and what something should be done Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 19 Scrum Master! David Broman davbr@ida.liu.se! Roles • Team • Product Owner • Scrum master • Make sure the scrum team adheres Scrum values, practices and rules • Run meetings • Protects the team from disturbance • Collects and removes obstacles (Impediment list) Lists • Product backlog • Sprint backlog • Impediment list The scrum master may not • Mange the scrum team the scrum team is self-organized Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Scrum master cannot be product owner Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 20 Pigs and Chickens! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • Scrum team members are ”pigs” • Everyone else is a ”chicken” • Chickens cannot tell ”pigs” how to do their work ”A chicken and a pig are together when the chicken says ”Let’s start a restaurant!”. The pig thinks it over and says ”What would we call this restaurant?” The chicken says ”Ham n’ Eggs!” The pig says ”No thanks, I’d be committed, but you would only be involved!” Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 21 David Broman davbr@ida.liu.se! Exercise Project leading and selforganization ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 22 Product Backlog (2)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • List of product backlog items (PBI) (approx. List of potential requirements) • Prioritized • Available • Never complete • Features, bug fixes, documentation, tests etc. • Value (PO) and estimates (Team) • PO responsible, everyone can add Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Release planning meeting (3)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list 23 David Broman davbr@ida.liu.se! • Initial meeting – create initial backlog • Short meetings, end of each sprint - Update and prioritize product backlog Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Sprint planning, Part 1, what (4)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Part 1 – ”What” (4) • Break down top items • Estimate product backlog • Select PBIs for a sprint • Time-boxed 4h Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Optional: Sprint GOAL Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 24 David Broman davbr@ida.liu.se! 25 Prioritization of requirements! David Broman davbr@ida.liu.se! Customer ! Value! High! Sweet Spot Low! Avoid Low! High! Development Effort! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Effort Estimation… a good approach?! 26 David Broman davbr@ida.liu.se! No idea. I have never done this before... I wonder if it is even possible. How long time does it take for you to implement the encryption layer? 8 months +- 2 months Sam! the seller! ! Part I! Processes and models in Software Engineering! Harry! the hacker! Part II! SCRUM! 27 Planning Poker ® - Exercise! Customer value estimation ! ! Talk to the customer!! David Broman davbr@ida.liu.se! 1. List things to be done to make my party great!! Effort estimation (Planning poker®)! ! ! ! Variant of the Delphi approach! Speed-up estimations! Everyone participate! 2. Prioritize the list in regards to customer value ! 3. Base line e.g., “Cook food” is 2. Relative estimation.! Choices: ? 0 ½ 1 2 3 5 8 13 20! 40 100 infinity! 4. Effort estimation for each item! - Read and discuss item (short) ! - Make a decision (privately)! - Show cards at the same time! - Highest and lowest argue! - Repeat until consensus! ! Part I! Processes and models in Software Engineering! Part II! SCRUM! Sprint planning, Part 2, how Sprint Backlog(6) ! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Part 2 - ”How” (5) • Design • Identify tasks • Estimate tasks (hours) • Output: Sprint backlog Sprint backlog • Consists of tasks • Less than 2 day (preferable hours) • Not ordered Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 28 David Broman davbr@ida.liu.se! 29 Task Board (6)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! Task Board • Not defined by Scrum • Use non high-tech • Example of columns • PBI • Todo • In Process • To Verify • Done Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 30 Sample Task Board! ! Part I! Processes and models in Software Engineering! David Broman davbr@ida.liu.se! Part II! SCRUM! 31 Done! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • When are we done? • “No more remaining work” • Includes testing, documentation etc. • Possible to ship after each sprint • Everybody – understand what done means Tools to support done • Version handling (SCM) • Automated build • Automated tests (Continuous integration) Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 32 Burn-down Chart (7)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! Burn-down chart • Only track hours remaining, not hours worked • X – days (in Sprint) • Y – hours remaining • Remove meeting time, vacation etc. from total available hours • Update only when PBIs are DONE • Slope – the team velocity. • When not done – Undone PBIs Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 33 Daily Scrum (8)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • Stand-up meeting • Scrum master runs the meeting • Every morning • Time-boxed 15min • 1 minute each person • Do NOT solve problems! • Chickens are not allowed to talk Questions • What did you do yesterday? • What will you do today? • What impediments stand in your way? Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 34 David Broman davbr@ida.liu.se! Exercise Daily Scrum - Theater ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 35 Impediment List! Roles • Team • Product Owner • Scrum master David Broman davbr@ida.liu.se! • List of obstacles • Scrum Master’s backlog • Daily update • Open, visible and honest Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 36 Sprint review (9)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • Time-boxed 4h • End of sprint • Team + Scrum Master + Product owner (potentially also customer) • Informal meeting – what has been done • Demonstrate – no power points • Show working functionality – get feedback Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 37 Sprint retrospective (10)! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective David Broman davbr@ida.liu.se! • 3h, time-boxed • Inspect the last sprint, regarding • People • Relationships • Processes • Tools • How to make things better – process improvements • What was good? • What was not so good? • How can we improve? Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM! 38 SCRUM! David Broman davbr@ida.liu.se! Roles • Team • Product Owner • Scrum master Lists • Product backlog • Sprint backlog • Impediment list Meetings • Release planning • Sprint planning • Daily Scrum • Sprint review • Sprint retrospective Thanks for listening! Sprint, Task board, Burn-down chart, Done, Velocity ! Part I! Processes and models in Software Engineering! Part II! SCRUM!
