DOCSLIB.ORG

Agile Planning and Project Management Mike Cohn Agile 2013 August 5, 2013

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Agile Planning and Project Management Mike Cohn Agile 2013 August 5, 2013 Agile Planning and Project Management Mike Cohn Agile 2013 August 5, 2013 1 Mike Cohn • Founding member of Agile Alliance & Scrum Alliance • Founder of Mountain Goat Software • Doing Scrum since 1995 • Started my career as a programmer • VP Engineering in 4 companies ® 2 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 3 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 4 Iterative • Revisit previously worked-on pieces © Copyright Mountain Goat Software ® 5 Incremental • Develop one piece at a time © Copyright Mountain Goat Software ® 6 Iterative & incremental • Do some of one part then some of the next © Copyright Mountain Goat Software ® 7 Six levels of planning Strategy Portfolio Product Team focuses here Release Team focuses here Iteration Team focuses here Daily © Copyright Mountain Goat Software ® 8 A release plan Iteration 1 Iteration 2 Iteration 3 Iterations 4–7 IeaiIne Paain Pa Cd hC …d h …6 8 Dcd … 4 Ts h … 1 Ts h … 6 Dsg a … 8 Atmt … 8 Cd h … 6 ® © Copyright Mountain Goat Software 9 Agenda • Iterative and incremental • User stories • Estimating • Planning ® © Copyright Mountain Goat Software 10 A a ue, I at o A a vcto taee, rsre a htl I at o e poo ro. o h htl. A a feun flyr, I A a ue, I a cne wn o rbo a at a rsrain. t i o ht I ae ie boig tis I ae otn. © Copyright Mountain Goat Software ® 11 A template As a <user type>, I <want/need/can/etc.> some goal, [so that <reason>]. © Copyright Mountain Goat Software ® 12 Where are the details? A a ue, I a • Does the user get a full or partial refund? cne a • Is the refund to her credit rsrain. card or is it site credit? • How far ahead must the reservation be cancelled? • Is that the same for all hotels? • For all site visitors? Can frequent travelers cancel later? • Is a confirmation provided to the user? How? © Copyright Mountain Goat Software ® 13 Add details as A a peim ie sub-stories mme, I a cne p o h ls mnt. A a ue, I a A a nn-peim cne a mme, I ed o rsrain. cne t lat 4 hus n avne. A a mme, I m eald a cnfirain w©e Copyright I c Mountainne Goat. Software ® 14 … or as Conditions of Satisfaction • Conditions of Satisfaction are essentially tests • Should come from the product owner A a ue, I a cne a rsrain. Vrf ht a peim mme cn cne h ae a wtot a fe. Vrf ht a nn-peim mme s cagd 1% o a sm-dy cnelto. Vrf ht n eal cnfirain s sn. © Copyright Mountain Goat Software ® 15 Legend Tee Size Larger Ei Smaller Detail Less More Time © Copyright Mountain Goat Software ® 16 A a P Mreig, I a slc h tmfae o A a P Mreig, I a ue hn rveig h rve h promne promne f at o hsoia d cmags cmags, o ht … Eis? s ht I a ietf n A a P Mreig, I a rpa pofitbe oe. slc wih ye f cmags (drc mi, T, A ei eal, rdo, ec.) o icue hn rveig … © Copyright Mountain Goat Software ® 17 A a P Mreig, I at t e ifrain n drc miig hn rveig hsoia cmags. A a P Mreig, I at t e ifrain n T as hn rveig hsoia cm ags. A a P Mreig, I at t e ifrain n eal as hn rveig hsoia cmags. © Copyright Mountain Goat Software ® 18 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 19 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 20 How long to… • Drive to Seattle • Read a…ahem… good book 21 Estimate size; derive Size ➞ Calculation ➞ Duration 300 Velocity= 300÷20= kilograms 20 15 iterations © Copyright Mountain Goat Software ® 22 Two Units For ESTIMATING 1 2 Ideal Story Time Points © Copyright Mountain Goat Software ® 23 Ideal time • How long a thing will take if: • it’s all you work on • no one interrupts you © Copyright Mountain Goat Software ® 24 © Copyright Mountain Goat Software ® 25 Story points • How long a user story will take to develop (effort) • Influenced by • Complexity • Risk • Uncertainty • Etc. © Copyright Mountain Goat Software ® 26 27 Your time cannot be added to mine • You can run the trail in 5 minutes • I can run it in 10 minutes • We can’t agree on how long it will take to run • But we can agree the trail is 1 km © Copyright Mountain Goat Software ® 28 Planning Poker® • Each estimator has cards with valid estimates • A product backlog item is discussed • Each estimator selects an estimate • Cards are turned over • Discuss differences (especially outliers) • Repeat until consensus © Copyright Mountain Goat Software ® 29 Chris Susan Ann Vadim © Copyright Mountain Goat Software ® 30 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 31 Agenda • Iterative and incremental • User stories • Estimating • Planning © Copyright Mountain Goat Software ® 32 Velocity 50 45 40 42 40 40 38 39 Average 34 35 = 38 30 29 20 Story Points 10 0 Iterations © Copyright Mountain Goat Software ® 33 How much can 5×38➞ be delivered in 5 iterations? Product Backlog © Copyright Mountain Goat Software ® 34 Using a confidence interval 50 45 40 42 40 40 38 39 34 35 30 29 20 Story Points 10 0 Iterations © Copyright Mountain Goat Software ® 35 Calculating a confidence interval Iterations to # of throw out historical from each iterations each end 0–7 0 8–10 1 11–12 2 13–15 3 16–17 4 18–20 5 21–22 6 23–25 7 26+ 8 © Copyright Mountain Goat Software ® 36 Ue h oln vlct rne cluao t mutigasfwr .cm/tos © Copyright Mountain Goat Software ® 37 A better answer: 5×3442➞ • How much can Will have be delivered in 5 iterations? • Fixed-date planning Might have Won’t have Product Backlog © Copyright Mountain Goat Software ® 38 Fixed-scope projects • Sum the product backlog • Estimate velocity as a range • Divide the size of the product backlog by the velocity range JANUARY FEBRUARY MARCH APRIL MAY JUNE SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT 1 2 3 4 5 6 1 2 3 1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 1 2 3 41 52 7 8 9 10 11 12 13 4 5 6 7 8 9 10 4 5 6 7 8 9 10 8 9 10 11 12 13 14 6 7 8 9 10 11 12 63 47 58 69 107 118 129 14 15 16 17 18 19 20 11 12 13 14 15 16 17 11 12 13 14 15 16 17 15 16 17 18 19 20 21 13 14 15 16 17 18 19 1013 1411 1512 1613 1417 1518 1916 120÷20= 21 22 23 24 25 26 27 18 19 20 21 22 23 24 18 19 20 21 22 23 24 22 23 24 25 26 27 28 20 21 22 23 24 25 26 2017 2118 2219 2023 2421 2522 2623 28 29 30 31 25 26 27 28 25 26 27 28 29 30 31 29 30 27 28 29 30 31 2427 2528 2926 3027 2831 29 30 JANUARY FEBRUARY MARCH APRIL MAY JUNE JULY AUGUST SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT 1 2 3 4 5 6 1 2 3 1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 1 2 3 41 52 1 2 3 4 5 6 7 1 2 3 4 7 8 9 10 11 12 13 4 5 6 7 8 9 10 4 5 6 7 8 9 10 8 9 10 11 12 13 14 6 7 8 9 10 11 12 63 47 58 69 107 118 129 8 9 10 11 12 13 14 5 6 7 8 9 10 11 14 15 16 17 18 19 20 11 12 13 14 15 16 17 11 12 13 14 15 16 17 15 16 17 18 19 20 21 13 14 15 16 17 18 19 1013 1411 1512 1613 1417 1518 1916 15 16 17 18 19 20 21 12 13 14 15 16 17 18 120÷15= 21 22 23 24 25 26 27 18 19 20 21 22 23 24 18 19 20 21 22 23 24 22 23 24 25 26 27 28 20 21 22 23 24 25 26 2017 2118 2219 2023 2421 2522 2623 22 23 24 25 26 27 28 19 20 21 22 23 24 25 28 29 30 31 25 26 27 28 25 26 27 28 29 30 31 29 30 27 28 29 30 31 2427 2528 2926 3027 2831 29 30 29 30 31 26 27 28 29 30 31 © Copyright Mountain Goat Software ® 39 Mike Cohn [email protected] www.mountaingoatsoftware.com fb.com/mountaingoatsoftware linkedin.com/in/mikewcohn twitter: mikewcohn (888) 61–AGILE ® 40 Agenda • Iterative and incremental • User stories • Estimating • Planning • Tracking progress © Copyright Mountain Goat Software ® 41 Agenda • Iterative and incremental • User stories • Estimating Bonus Section • Planning • Tracking progress © Copyright Mountain Goat Software ® 42 Three Ways to Track Progress 1 2 3 Release Sprint Task Burndown Burndown Boards © Copyright Mountain Goat Software ® 43 A release burndown chart 360 270 180 7 Story Points 90 peitd vlct f 6 0 0 1 2 3 4 5 6 Iterations © Copyright Mountain Goat Software ® 44 Tasks Mon Tues Wed Thur Fri Code the UI 8 4 8 Code the middle tier 16 12 10 7 Test the middle tier 8 16 16 11 8 Write online help 12 50 40 30 20 Hours 10 0 Fri Mon Thur Wed Tues © Copyright Mountain Goat Software ® 45 Task boards Soy T D I Poes Dn A a ue, Cd te… I… Dsg a… 8 ps 8 hs Ts te… 8 hs Fgr u Fgr u h4w… hs hw… 8 r S 8 r A a nvc Cd te… ue, I… Dsg a… 8 t 8 hs Ts te… 8 hs 4 hs © Copyright Mountain Goat Software ® 46 Mike Cohn [email protected] www.mountaingoatsoftware.com fb.com/mountaingoatsoftware linkedin.com/in/mikewcohn twitter: mikewcohn (888) 61–AGILE ® 47.
Load more

Recommended publications
  • Rugby - a Process Model for Continuous Software Engineering
    INSTITUT FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rugby - A Process Model for Continuous Software Engineering Stephan Tobias Krusche Vollstandiger¨ Abdruck der von der Fakultat¨ fur¨ Informatik der Technischen Universitat¨ Munchen¨ zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Helmut Seidl Prufer¨ der Dissertation: 1. Univ.-Prof. Bernd Brugge,¨ Ph.D. 2. Prof. Dr. Jurgen¨ Borstler,¨ Blekinge Institute of Technology, Karlskrona, Schweden Die Dissertation wurde am 28.01.2016 bei der Technischen Universitat¨ Munchen¨ eingereicht und durch die Fakultat¨ fur¨ Informatik am 29.02.2016 angenommen. Abstract Software is developed in increasingly dynamic environments. Organizations need the capability to deal with uncertainty and to react to unexpected changes in require- ments and technologies. Agile methods already improve the flexibility towards changes and with the emergence of continuous delivery, regular feedback loops have become possible. The abilities to maintain high code quality through reviews, to regularly re- lease software, and to collect and prioritize user feedback, are necessary for con- tinuous software engineering. However, there exists no uniform process model that handles the increasing number of reviews, releases and feedback reports. In this dissertation, we describe Rugby, a process model for continuous software en- gineering that is based on a meta model, which treats development activities as parallel workflows and which allows tailoring, customization and extension. Rugby includes a change model and treats changes as events that activate workflows. It integrates re- view management, release management, and feedback management as workflows. As a consequence, Rugby handles the increasing number of reviews, releases and feedback and at the same time decreases their size and effort.
    [Show full text]
  • Towards a Discipline for Agile Requirements
    Forging High-Quality User Stories: Towards a Discipline for Agile Requirements Garm Lucassen, Fabiano Dalpiaz, Jan Martijn E.M. van der Werf and Sjaak Brinkkemper Department of Information and Computing Sciences Utrecht University Email: g.lucassen, f.dalpiaz, j.m.e.m.vanderwerf, s.brinkkemper @uu.nl { } Abstract—User stories are a widely used notation for formulat- which will remain impossible to achieve in the foreseeable ing requirements in agile development. Despite their popularity in future [11]. industry, little to no academic work is available on determining Instead, tools that want to harness NLP are effective only their quality. The few existing approaches are too generic or employ highly qualitative metrics. We propose the Quality User when they focus on the clerical part of RE that a tool can Story Framework, consisting of 14 quality criteria that user perform with 100% recall and high precision, leaving thinking- stories should strive to conform to. Additionally, we introduce required work to human requirements engineers [6]. Addition- the conceptual model of a user story, which we rely on to ally, they should conform to what practitioners actually do, subsequently design the AQUSA tool. This conceptual piece of instead of what the published methods and processes advise software aids requirements engineers in turning raw user stories into higher quality ones by exposing defects and deviations from them to do [12]. User stories’ popularity among practitioners good practice in user stories. We evaluate our work by applying and simple yet strict structure make them ideal candidates. the framework and a prototype implementation to multiple case Throughout the remainder of this paper we make five studies.
    [Show full text]
  • Agile Testing Practices
    Agile Testing Practices Megan S. Sumrell Director of Transformation Services Valtech Introductions About us… Now about you… Your name Your company Your role Your experience with Agile or Scrum? Personal Expectations Agenda Introductions Agile Overview Traditional QA Teams Traditional Automation Approaches Role of an Agile Tester Testing Activities Refine Acceptance Criteria TDD Manual / Exploratory Testing Defect Management Documentation Performance Testing Regression Testing Agenda Continued Test Automation on Agile Teams Testing on a Greenfield Project Testing on a Legacy Application Estimation Sessions Sprint Planning Meetings Retrospectives Infrastructure Skills and Titles Closing Agile Overview Agile Manifesto "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." Scrum Terms and Definitions User Story: high level requirements Product Backlog: list of prioritized user stories Sprint : one cycle or iteration (usually 2 or 4 weeks in length) Daily Stand-up: 15 minute meeting every day to review status Scrum Master: owns the Scrum process and removes impediments Product Owner: focused on ROI and owns priorities on the backlog Pigs and Chickens Traditional QA Teams How are you organized? When do you get involved in the project? What does your “test phase” look like? What testing challenges do you have? Traditional Test Automation Automation Challenges Cost of tools Hard to learn Can’t find time Maintenance UI dependent Only a few people can run them Traditional Test Pyramid UNIT TESTS Business Rules GUI TESTS Will these strategies work in an Agile environment? Food for Thought…….
    [Show full text]
  • User Stories.Book
    User Stories Applied for Agile Software Development Mike Cohn Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Chapter 2 Writing Stories In this chapter we turn our attention to writing the stories. To create good sto- ries we focus on six attributes. A good story is: • Independent • Negotiable • Valuable to users or customers •Estimatable •Small •Testable Bill Wake, author of Extreme Programming Explored and Refactoring Workbook, has suggested the acronym INVEST for these six attributes (Wake 2003a). Independent As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and plan- ning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority. Dependencies between stories can also make estimation much harder than it needs to be. For example, suppose we are working on the BigMoneyJobs website and need to write stories for how companies can pay for the job openings they post to our site. We could write these stories: 1. A company can pay for a job posting with a Visa card. 2. A company can pay for a job posting with a MasterCard. 17 18 WRITING STORIES 3. A company can pay for a job posting with an American Express card. Suppose the developers estimate that it will take three days to support the first credit card type (regardless of which it is) and then one day each for the second and third.
    [Show full text]
  • User-Stories-Applied-Mike-Cohn.Pdf
    ptg User Stories Applied ptg From the Library of www.wowebook.com The Addison-Wesley Signature Series The Addison-Wesley Signature Series provides readers with practical and authoritative information on the latest trends in modern technology for computer professionals. The series is based on one simple premise: great books come from great authors. Books in the series are personally chosen by expert advi- sors, world-class authors in their own right. These experts are proud to put their signatures on the cov- ers, and their signatures ensure that these thought leaders have worked closely with authors to define topic coverage, book scope, critical content, and overall uniqueness. The expert signatures also symbol- ize a promise to our readers: you are reading a future classic. The Addison-Wesley Signature Series Signers: Kent Beck and Martin Fowler Kent Beck has pioneered people-oriented technologies like JUnit, Extreme Programming, and patterns for software development. Kent is interested in helping teams do well by doing good — finding a style of software development that simultaneously satisfies economic, aesthetic, emotional, and practical con- straints. His books focus on touching the lives of the creators and users of software. Martin Fowler has been a pioneer of object technology in enterprise applications. His central concern is how to design software well. He focuses on getting to the heart of how to build enterprise software that will last well into the future. He is interested in looking behind the specifics of technologies to the patterns, ptg practices, and principles that last for many years; these books should be usable a decade from now.
    [Show full text]
  • Selecting a Development Process: Choosing Among the Leading Alternatives Mike Cohn Mountain Goat Software [email protected]
    Selecting a Development Process: Choosing Among the Leading Alternatives Mike Cohn Mountain Goat Software [email protected] Copyright Mountain Goat Software, LLC 1 Mike Cohn - background Copyright Mountain Goat Software, LLC 2 Today’s agenda Considerations Team Software Proce ss Scrum Extreme Programming OpenUP/Basic Rational Unified Process Copyright Mountain Goat Software, LLC 3 Ceremony • The amount of formalism in a process • Documentation, method weight, reviews Few documents Many documents Few steps Formal steps Copyright Mountain Goat Software, LLC 4 Cycles Sequential • Number and length of iterations Few documents Many documents Few steps Formal steps Many short iterations (5 days) Copyright Mountain Goat Software, LLC 5 Placing the processes Sequential Few documents Many documents Few steps Formal steps Many short iterations (5 days) Copyright Mountain Goat Software, LLC 6 Today’s agenda Considerations Team Software Proce ss Scrum Extreme Programming OpenUP/Basic Rational Unified Process Copyright Mountain Goat Software, LLC 7 Team Software Process (TSP) • Created by Watts Humphrey • Of Software Engineering Institute and Capability Maturity Model (CMM) • Builds on his Personal Software Process • High discipline, highly defined • A “cyclic development strategy” • Another way of saying “iterative and incremental” Copyright Mountain Goat Software, LLC 8 Goals of the TSP 1. Build on the Personal Software Process 2. Develop products in cycles 3. Establish standard measures for quality and performance 4. Provide precise measures
    [Show full text]
  • San José State University Computer Science Department CS160, Software Engineering, Section 4, Spring 2018
    San José State University Computer Science Department CS160, Software Engineering, Section 4, Spring 2018 Course and Contact Information Instructor: Fain (Frank) Butt Office Location: MH212 Telephone: (408) 924-5060 Email: [email protected] Office Hours: TR 8:45 PM – 10:00 PM (by appointment) Class Days/Time: Section 4: TR 7:30 - 8:45 PM Classroom: MH222 Prerequisites: Prerequisite: CS 146, CS 151 (with a grade of "C-" or better in each); CS 100W (with a grade of "C" or better) Course Format All your programming project deliverable must be able to compile and run before packaging for submission. Otherwise you will not earn many points if we can’t verify your results. You are expected to spend 15-20 hours a week on homework and/or project. Faculty Web Page and MYSJSU Messaging Course syllabus and the rest of the course information will be published via Canvas. You are responsible for regularly checking with the messaging system through MySJSU and Canvas to learn of any updates. Course Description Software engineering principles, requirements elicitation and analysis, design, configuration management, quality control, project planning, social and ethical issues. Required team-based software development, including written requirements specification and design documentation, oral presentation, and tool use. Course Learning Outcomes (CLO) Upon successful completion of this course, students will be able to: 1. CLO 1 – Design and build a project from end to end 2. CLO 2 – Write a Requirement Document 3. CLO 3 – Write High-level and low-level designs 4. CLO 4 – Iterative Implementation 5. CLO 5 – Understanding Different Stages of Quality Assurance 6.
    [Show full text]
  • Best Agile Articles of 2017
    Best Agile Articles of 2017 Editors: Michael de la Maza, CEC & Cherie Silas, CEC BEST AGILE ARTICLES OF 2017 Edited By: Michael de la Maza, CEC & Cherie Silas, CEC Copyright ©2018 by Michael de la Maza All rights reserved. Printed in the United States of America. Cover design by Christopher Kyle Wilson The text of this book is set in Warnock Pro & Myriad Pro Book layout by THDesign, Inc. First Edition: November 2018 ii Table of Contents Foreword .................................................................................................................................................................................................Page vii Pete Behrens Lean Startup has Changed Nothing! ..................................................................................................Pages 9–13 Sonja Blignaut If you want to innovate, don’t say so ................................................................................................Pages 14–18 Melissa Boggs At the Intersection of Culture & Strategy ...................................................................................Pages 19–21 Zach Bonaker Scrum Guide Sliders ....................................................................................................................................Pages 22–26 Braz Brandt Agile in Highly Regulated Environments ....................................................................................Pages 27–30 Maxime Castera What Kids Taught Me About Being Agile...................................................................................Pages
    [Show full text]
  • To View Or Download This Issue PDF File, 670 K
    METHODS & TOOLS Global knowledge source for software development professionals ISSN 1661-402X Fall 2005 (Volume 13 - number 3) Man-Machine Interface The reduction of the transformation activities between man thoughts and executable software has been the quest of the software development world for a very long time. Behind this objective is the fact that the translation process to executable instructions is where distortions and errors are created. Among the solutions adopted to try to solve this problem, we can mention the approach that wants to express computer instructions in syntax as close as possible to "natural language" and the efforts to transform specifications automatically in executable code. With the natural language approach, you meet quickly the barrier of giving a clear meaning to natural language. If you have tried to build a general interpreter, you have seen how difficult it is to manage the input of natural language. In a similar approach, attempts have been made to create programming languages with "verbose" syntax so that they could be understood easily by non-programmers. The "automatic transformation" road is close to the previous approach but recognise that a special language is needed to express requirements. Its difficulties are the creation of a specification language that can be understood by the end-users and the detail of specifications needed before code generation. Maintaining different levels of abstraction is not easy and you could simply end by writing your code in a high level language. Both solutions generate even more complexity if you try to implement them so that they could be applicable to all problem domains.
    [Show full text]
  • Release Planning Meeting
    John Blanco Agile Transformation Consultant The Eliassen Group Playing the Pointing Game “Before you commission a painter to decorate your home or a mechanic to fix your car, you get an estimate from them, right? You need to know how much it’s likely to cost and how long it might take. It’s just common sense.” - David Morris, Estimating on Agile Projects: What’s the story, what’s the point? Agenda Old vs. New Where we came from and why we need to change Why Points? Why Fibonacci? Understanding basic units of measure The Art of Relative Sizing Some Ceremonies around pointing SAFe: Normalized Pointing Why Time matters Complexity Clusters Helping the team thru the transition Balancing Buffers, Invisible Load Q&A Where we came from and why we need to change BUSINESS Products VALUE Customer Delight Services Self Worth Accountability Cadence Quality Self-governing Teams Velocity Reusability Goal Oriented Metrics TDD/ATDD/CI Clarity Predictability DevOps Synchronization PEOPLE PROCESS TECHNOLOGY culture engineering Scrum XP Services Roles Kanban Platforms Rituals Lean Startup Business Applications Responsibilities SAFe Development/Support Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation AGILE Responding to change over following a plan principles Foundation and Philosophy structure Where we came from and why we need to change we started with this… Front end planning Sizing using task duration Sizing done by the elite Uncertainty vs. Time (Boehm) …and we forgot about this People are fickle – ideation & creativity can not be frozen Requirements harden as the product evolves Where we came from and why we need to change we started with this… Front end planning Sizing using task duration Sizing done by the elite Uncertainty vs.
    [Show full text]
  • The 7Th International Conference on Extreme Programming and Agile
    ESPOO 2006 VTT SYMPOSIUM 241 This proceedings is a collection of all the tutorials, workshops, activities VTT SYMPOSIUM 241 and keynote speeches of the 7th International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP 2006) held in June 17–22, 2006, Oulu, Finland. The 7th International Conference on eXtreme Programming and Agile... The 7th International Outi Salo, Pekka Abrahamsson & Päivi Järing (eds.) The 7th International Conference on eXtreme Programming and Agile Processes in Software Engineering Tutorials, Workshops, Activities, Tätä julkaisua myy Denna publikation säljs av This publication is available from VTT VTT VTT and Keynote Speeches PL 1000 PB 1000 P.O. Box 1000 02044 VTT 02044 VTT FI-02044 VTT, Finland Puh. 020 722 4404 Tel. 020 722 4404 Phone internat. +358 20 722 4404 Faksi 020 722 4374 Fax 020 722 4374 Fax +358 20 722 4374 ISBN 951–38–6305–0 (soft back ed.) ISBN 951–38–6306–9 (URL: http://www.vtt.fi/inf/pdf/) ISSN 0357–9387 (soft back ed.) ISSN 1455–0873 (URL: http://www.vtt.fi/inf/pdf/) VTT SYMPOSIUM 241 Keywords: software engineering, eXtreme programming, agile processes, adaptive processes, agile development, software development, XP projects, testing The 7th International Conference on eXtreme Programming and Agile Processes in Software Engineering Tutorials, Workshops, Activities, and Keynote Speeches Oulu, Finland, June 17–22, 2006 Edited by Outi Salo, Pekka Abrahamsson & Päivi Jaring VTT Technical Research Centre of Finland Organised by VTT Technical Research Centre of Finland University of Oulu ISBN 951–38–6305–0 (soft back ed.) ISSN 0357–9387 (soft back ed.) ISBN 951–38–6306–9 (URL: http://www.vtt.fi/publications/index.jsp) ISSN 1455–0873 (URL: http://www.vtt.fi/publications/index.jsp) Copyright © VTT Technical Research Centre of Finland 2006 JULKAISIJA – UTGIVARE – PUBLISHER VTT, Vuorimiehentie 3, PL 1000, 02044 VTT puh.
    [Show full text]
  • Impact of Unified User-Story-Based Modeling on Agile Methods: Aspects on Requirements, Design and Life Cycle Management by Samedi Heng
    Impact of Unified User-Story-Based Modeling on Agile Methods: Aspects on Requirements, Design and Life Cycle Management by Samedi Heng A thesis submitted in fulfillment of the requirements for the degree of Doctor in Economics and Management Sciences of the Université catholique de Louvain Examination Committee: Prof. Manuel Kolp (UCLouvain), Advisor Prof. Yves Wautelet (KULeuven), Co-Advisor Prof. Jean Vanderdonckt (UCLouvain), Examiner Prof. Isabelle Mirbel (Université Nice Sophia Antipolis), Examiner Prof. Vincent Englebert (UNamur), Reader Prof. Per Agrell (UCLouvain), President of the jury February 2017 To my parents, for your hard work and sacrifices to support our family and, more importantly, your vision that only better education can improve our standards of living to increased enjoyment and happiness. Acknowledgements As long as I remember, writing a PhD thesis has always been a dream. It has been a unique experience comparable to no others I have had before. It took me six years to finally made it to the end. This would not have been possible without the precious help and encouragements from the people I thank hereafter. First, I would like to express my sincere gratitude to my supervisors Profs. Manuel Kolp and Yves Wautelet. Yves once told me that the path to the PhD is made of ups and downs; downs can be the periods when most of the improvements are there to put yourself into question which is, by nature, the essence of any scientific work. My personal path has also been made of these with a down peak in 2013. Both of you helping me back on my feet in a hard but fair manner made of interventions and coaching but also encouragements, advices, and amusement.
    [Show full text]