Scrum Development. Overview. Fabrizio Morando. Application Development Manager

Transcription

1 Scrum Development Overview Fabrizio Morando Application Development Manager venerdì 30 novembre 2012

2 Scrum in 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

3 Scrum origins Jeff Sutherland Initial scrums at Easel Corp in 1993 IDX and 500+ people doing Scrum Ken Schwaber ADM Scrum presented at OOPSLA 96 with Sutherland Author of three books on Scrum Mike Beedle Scrum patterns in PLOPD4 Ken Schwaber and Mike Cohn Co-founded Scrum Alliance in 2002, initially within the Agile Alliance

4 Scrum has been used by: Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Esta BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

5 Scrum has been used for: Commercial software In-house development Contract development Fixed-price projects Financial applications ISO 9001-certified applications Embedded systems 24x7 systems with % uptime requirements the Joint Strike Fighter Video game development FDA-approved, life-critical systems Satellite-control software Websites Handheld software Mobile phones Network switching applications ISV applications Some of the largest applications in use

6 Characteristics Self-organizing teams Product progresses in a series of month-long sprints Requirements are captured as items in a list of product backlog No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects One of the agile processes

7 Why Agile Agile software developmment is a group of lightweight software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross functional teams. Main elements of agile: o Iterative o Adaptable o Rapid o Cooperative o Quality Driven

8 Agile: What are the benefits? Iterative and adaptive Customer can see quickly at what stage the development is Every 2-4 week there s a potentially shippabile product increment Feedback is given routinely and often Plans are in short durations (iterations) so change can be implemented quicker Wasted development is reduced Prioritized features developed as mandatory

9 Why working software Working software encourages feedback when users can see and touch the product they can immediately tell if it is what they want Working software helps a team gauge its progress work shown to be complete allows for real progress to be identified Working software allows product to be shipped early if desired the opion to ship early can be very valuable to your customer to allow for markets that change rapidly

10 The Agile Manifesto a statement of values Individuals and interactions Working software Customer collaboration Responding to change over over over over Process and tools Comprehensive documentation Contract negotiation Following a plan Source:

11 Close to Certainty Far from Certainty Requirements Project noise level Far from Agreement Complex Anarchy Close to Agreement Simple Technology Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

12 What is Scrum? Scrum employs an iterative, incremental approach to optimize predicability and control risk A holistic or rugby approach where a team tries to go to the distance as unit, passing the ball back and forth may better serve today s competitive requirements Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, Harvard Business Review, January 1986.

13 Scrum 24 hours Sprint goal Sprint 2-4 weeks Return Cancel Return Gift Coupons wrap Gift Cancel wrap Product backlog Sprint backlog Coupons Potentially shippable product increment

14 Putting it all together Image available at

15 Agile : Scrum framework Scrum should not be viewed as a collection of practices but rather as a culture or a set of values - Ken Schwaber Basic principals are: o Define success o Define failure o Optimize the process for success

16 Agile : Scrum framework Scrum employs an iterative, incremental approach to optimize predicability and control risk upon three pillars of empirical process control: Transparency o The aspects of the process that affect the outcome are visible Inspection o Frequent enaugh inspection allow the detection of unacceptable variances Adaption o If inspection reveals elements outside acceptable limit possible to minimize further deviation

17 Agile : Scrum framework Planning Doing Predictive: All planning is done at the beginning Empirical: JIT planning and replanning based on frequent inspection Planning Doing P D P D P D

18 Agile : Demming cycle (PDCA) Sprint Retrospective Sprint Planning Act Plan Check Do Daily Scrum Burndown charts Impediments Sprint

19 Sprints Scrum projects make progress in a series of sprints Analogous to Extreme Programming iterations Typical duration is 2 4 weeks or a calendar month at most A constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint

20 Sequential vs. overlapping development Requirements Design Code Test Rather than doing all of one thing at a time......scrum teams do a little of everything all the time Source: The New New Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January 1986.

21 No changes during a sprint Change Plan sprint durations around how long you can commit to keeping change out of the sprint

22 Scrum framework Roles Product owner ScrumMaster Team Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifacts Product backlog Sprint backlog Burndown charts

23 Scrum framework Roles Product owner ScrumMaster Team Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifacts Product backlog Sprint backlog Burndown charts

24 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 Owns the Product Backlog Accepts work as completed (Done) Negotiates priorities with team Get stakeholders to define roadmap Manage relationship with stakeholders

25 The ScrumMaster Represents management of SCRUM (not a team leader) Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Enable close cooperation across all roles and functions Shield the team from external interferences

26 The ScrumMaster Ensures the SCRUM process is followed and understood No formal authority over dev team (except on following the process) FACILITATOR Works with PO to maximize ROI and meet objectives Improve the engineering practices and tools so that each increment of functionality is potentially shipped Handling time in sprint planning meetings to ensure the sprint contains «non productive» time Ensure Definiton of Done (DoD) agreed Does not assign tasks to team members Does not make decisions for team without their authority

27 The team Typically 5-9 people Cross-functional: Programmers, testers, user experience designers, etc. Members should be full-time May be exceptions (e.g., database administrator) «The development team consists of developers with all the skills to turn the PO s requirements into a potentially releasable slice of the product by the end of a sprint»

28 The team Teams are self-organizing o Ideally, no titles but rarely a possibility Membership should change only between sprints Testers are part of the cross functional development team: o Interfacing with devs and PO to make sure stories are understood and acceptance test track desired functionality o Writing acceptance test code while code is written o Develop ongoing test automation to integrate acceptance and feature tests into C.I. environment

29 Scrum framework Roles Product owner ScrumMaster Team Ceremonies Release planning Sprint planning & Sprint Sprint review Sprint retrospective Daily scrum meeting Artifacts Product backlog Sprint backlog Burndown charts

30 Release Planning meeting Purpose is to decide: HOW WHAT WHEN HOW HOW can we trun the vision into a winning product HOW can we meet or exceed the desired customers satisfaction HOW can we make the ROI WHAT MOSCOW Mst,Should,Could,Would Risk \ Goal Re-estimating and re-prioritising WHEN Probabile delivery date Number of sprints based on what is known

31 Requirements Management C 75% of the estimated Effort (more is a risk) S M It s a negotiation With customer

32 Release Planning meeting Four Variables Scope: How much is to be done Resources: How many people are available Time: When will it be completed Quality: How good and how it well is tested DoD

33 Sprint Planning Meeting Team capacity Product backlog Business conditions Current product Technology Sprint planning meeting Sprint prioritization Analyze and evaluate product backlog Select sprint goal Sprint planning Decide how to achieve sprint goal (design) Create sprint backlog (tasks) from product backlog items (user stories / features) Estimate sprint backlog in hours Sprint goal Sprint backlog

34 Sprint Planning Meeting 1 The team decide how it will turn what was selected during the first half of the meeting (sprint prioritization) into a done increment 2 Team design work 3 Breakdown work into tasks 4 Task list is detailed pieces of work (sprint backlog) 5 Task should be less than one day work 6 Team can assing work here or JIT during a sprint

35 Sprint Planning Meeting Sprint backlog is product backlog decomposition o PBI s are often decomposed by acceptance tests o Depending on time, sprint work for the next several days is less than one day in lenght, larger sprint work can be decomposed during the sprint o Development team members sign up for work they are not assigned o Work for the sprint emerges o Work remaining is re-esitmated and updated daily

36 Sprint A time-boxed period of software development An iteration A given list of goals Typically 2-4 weeks in lenght Team work on the set of features defined in the sprint planning meeting This may lead to some critical questions

37 Sprint Scrum master facilitates Team work without interruptions No additions to User Stories are allowed Tasks may be re-estimated \ created \ cancelled on the way Team choose what they want to work on from sprint backlog

38 Definition of Done Needs to be defined in advance Clearly stated Agreed by PO and team Conditions of satisfaction Dod must be understood by everyone in the scrum team!!!

39 Sprint: Abnormal Termination Sprints can be terminated or abandones before the timebox PO is the only one who can cancel a sprint Termination can happen for variuos reasons: changes in competition, technology, business It is time consuming to cancel a sprint because you have to have a sprint review for work that has been completed, understand what to do with the unone work, hold a retrospective and re-plan for another sprint

40 Sprint planning meeting Team selects items from the product backlog they can commit to completing Sprint backlog is created Tasks are identified and each may be estimated (1-16 hours) Collaboratively, not done alone by the ScrumMaster High-level design is considered As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)

41 The daily scrum Parameters Daily 15-minutes Stand-up Not for problem solving Whole world is invited Only team members, ScrumMaster, product owner, can talk Helps avoid other unnecessary meetings

42 Everyone answers 3 questions What did you do yesterday? 1 What will you do today? Is anything in your way? 2 3 These are not status for the ScrumMaster They are commitments in front of peers

43 Daily Scrum : Why To enable communication and collaboration between team members To give focus and ensure sprint is still on track Used a the smallest tightest feedback loop To enable understanding of impediments or problems that may arise and that are hindering current sprint Facilitates actions for discussion later Show ability for self organization and task sharing Ability to identify quickly any issues arising

44 Daily Scrum: Who Attendees: Pigs: committed members Chickens: Involved members Scrum master, Product Owner, Team Customer, Management, Stakeholders, etc.. Only mandatory attendees speak to each other Chickens are there to observe

45 The 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

46 Sprint review Held at the end of every sprint to assess progress against the sprint goal and for everyone involved including customers, management and stakeholders to inspect what was produced in the last sprint, to see progress and to give acceptance or feedback. Show how team have delivered on its committments Show overall progess Review functionality that has been completed Review product backlog

47 Sprint review Show how team have delivered on its committments Scrum Master should review and summarize the sprint goal Scrum Master should then present a summary of the work accomplished on the sprint How many stories did we plan? Haw many points did we plan Dod Effort to be invested How many stories are done How many story points completed Effort: planned vs actual

48 Sprint review Show overall progess Show the update Release Burndown chart Look at quality Number of unit & acceptance tests defined ad passed, Number of bugs Review cost against the project

49 1 2 3 Sprint review Review functionality that has been completed Demonstrate Finished functionality Do they fulfil the agreed conditions of satisfaction? Discuss what has been seen and what to do next Do not show partially completed work!

50 Sprint review Review product backlog Discuss what has been seen and what to do next Reprioritize product backlog if necessary That should be easy: best practice is to detail forecast at least the next 2 sprints

51 Sprint retrospective Periodically take a look at what is and is not working Typically minutes Done after every sprint Whole team participates ScrumMaster Product owner Team Possibly customers and others

52 Start / Stop / Continue Whole team gathers and discusses what they d like to: What went right Start doing Stop doing What went wrong What would we change Actions to be assigned Continue doing This is just one of many ways to do a sprint retrospective. Can include discussion on processes, practices, communication, environment, artefacts, tools, etc

53 Scrum framework Roles Product owner ScrumMaster Team Ceremonies Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifacts Product backlog Sprint backlog Burndown charts

54 Product backlog This is the 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 Prioritized and owned by the product owner Groomed by team Reprioritized at the start of each sprint

55 A sample product backlog Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. As a guest, I want to change the dates of a reservation. As a hotel employee, I can run RevPAR reports (revenue-per-available-room) Improve exception handling

56 Sample Product Backlog

57 Product Backlog: DEEP Detailed Prioritized DEEP Estimated Emergent

58 PB: Detailed Appropriately Higher priority items described in more detail, smaller and more coincise, lower priority items have less detal as they cam be detailed later in the release. This keeps the backlog concise, as a consequence requirements are discovered throughout the project. Product discovery is ongoing

59 PB: Estimated and Emergent Estimated The PB items are roughly estimated in story points or days leave detailed planning to the sprint planning meeting Emergent The PB evolves throughout the project, the content changes with user feedback and as the product is developed new areas can be uncovered IT IS DYNAMIC!!!

60 PB: Prioritised All items are prioritised, the most important are implemented first. Useful factors for prioritising are: Value, knowledge, uncertainty, risk, releasability and dependences Priorities direct team s work Yes they are there!

61 PB: Rules of thumb Try to keep PB list to less then 100 items Group related items into 1 PBI to be managed as a group Remove items not directly aligned with the product roadmap (the sounds like a good idea The top 20 to 40 highest priority items are an appropriate size to fit into the development team upcoming sprints Use velocity after 1 or 2 sprints Put acceptance criteria on top pbi s Ensure the sprint has the same lenght to bring rhythm to the team Every PBI should have a value and a business benefit Generate a release burndown from emergent PB

62 PB: Grooming Remember to groom the PB often Ongoing process New requirements that are added to bottom of the PB when discovered Prioritise new PBI s Hight priority requirements are deomposed and prepared for next sprint planning Requirements are estimated Team reserve about 10% of their availability for grooming during a sprint Ensure next sprint or two s probable PB is actionable

63 The sprint goal A short statement of what the work will be focused on during the sprint Database Application Make the application run on SQL Server in addition to Oracle. Life Sciences Support features necessary for population genetics studies. Financial services Support more technical indicators than company ABC with real-time, streaming data.

64 Sprint Backlog Newly Added!!!

65 Managing the sprint backlog List of tasks the scrum team is committing they will complete in the current sprint Pulled together during the sprint planning meeting Team decide on the items and time required to complete them Scrum master updates during sprint to reflect which tasks are completed

66 Managing the sprint backlog Individuals sign up for work of their own choosing Work is never assigned this promotes self organization 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

67 A sprint backlog Features are broken into tasks Try to break down into about one day work Tasks Mon Tues Wed Thur Fri Code the user interface Code the middle tier Test the middle tier Write online help 12 Write the foo class Add error logging 8 4

68 Sprint Backlog 9 tips for creating a good SB (from Scrum Alliance ) Involve every team member Discuss how every SBI should be implemented Have a DoD Identify all kinds of tasks Don t estimate tasks at all Don t assign tasks up front Review Sprint committmen t Don t use too much time Evolve the SB during the sprint

69 Hours A sprint burndown chart

70 Hours Tasks Code the user interface Code the middle tier Test the middle tier Write online help Mon Tues Wed Thur Fri Mon Tue Wed Thu Fri

71 Agile: Estimating Why do it? Reducing \ Highlighting risk Reducin uncertainty Support better decision making Estabilish trust Conveying information IT IS NOT COMMITTING!!! Estimates are not set in a stone They are a base

72 User Stories These are used for describing requirements or features form the prespective of the person or user who desires the new feature or capability of the system As a <type of user> I want <some goal> so that <some reason> OR In order to <benefit> as a <type of user> I can <feature>

73 User stories US s drive the release and sprint planning Can be delivered withing a sprint Each story must have a condition of satisfaction Estimatable Small Testable

74 As a library clerk I want to be able to check out a book, know who has the book and how long they can have it before it is due back At the library As a borrower, I want to be able to take a book out and keep it for two weeks Break down into smaller stories!!!

75 User Stories I - Independent N - Negotiable V - Valuable E Estimable S Small T Testable Are they stand alone Capture the essence but can add more over time Is this valuable to the customer and to the buiness Can the story be estimated Smaller stories tend to be sized more accurately What are the acceptance test

76 User Stories Acceptance tests: Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer expects it to work These need to be completed for every user story These are the TOOL for the PO to accept the story and the development team to know when they are done to enable them to get acceptance of a US

77 User Stories vs Tasks Are in the customer language!!! User Stories Are in the developer language Are written as small discrete items of work Are the detailed plan for the sprint Tasks

78 User Stories : Pointing Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work We assing a point value on each item The raw values are unimportant it is the relative values that are important: a story that is 4 points must be double to the size of one thai is 2 points and half the size of one that is 8 points A good way to start pointing is to look at a medium story\task that is easily measured, assign it a number of points and than base all other on that choice

79 User Stories : Pointing Use various methods T-shirt Delphi Scale Poker cards RPS S M L Assign points independently than discuss and assign again (and again, and again ) 0,1,2,3,5,8,13,20 Each member has a set of cards with points and declares his\her hand Rock Paper Scissors

80 Velocity In an agile world, velocity is the amount of work the team is able to do in one iteration It can be based on experience from previous sprints or estimated for the first couple of sprints Prefer empirical measure to real time (using days \ hours is not sugegested) Calculation with story points is a statistical way to measure progress. If you use the same prerequisite and facts each time, you get better at measuring how many points can be delivered in a sprint DO NOT COMPARE VELOCITY BETWEEN TEAMS!!!

81 Scalability Typical individual team is 7 ± 2 people Scalability comes from teams of teams Factors in scaling Type of application Team size Team dispersion Project duration Scrum has been used on multiple 500+ person projects

82 Scaling through the Scrum of scrums

83 Scrum of scrums of scrums

84 Where to go next m scrumdevelopment@yahoogroups.co m

85 A Scrum reading list Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen

86 A Scrum reading list Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber Succeeding with Agile by Mike Cohn User Stories Applied for Agile Software Development by Mike Cohn

87 Copyright notice You are free: to Share to copy, distribute and and transmit the work to Remix to adapt the work Under the following conditions Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Nothing in this license impairs or restricts the author s moral rights. For more information see

88 Contact information Presentation by: Mike Cohn m (720) (office)

89 Thank You