Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Fantasies of an Agile Scrum Master

No description

Sarah Wren

on 26 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Fantasies of an Agile Scrum Master

Background User Story Examples What Are User Stories? Fantasies of an Agile Scrum Master (cc) photo by Franco Folini on Flickr Requirements are not fully understood before the project begins (Ziv's Law) Users know what they want only
after they see an initial version of
the software (Humphrey's Law) Requirements change often during
the software construction process
(over 60%) Most software features are rarely
or never used (64%) A User Story Is... Benefits As a user I want to be able to choose a user name when I register so that it can be personalized
As a user I want to be able to change my default password after I register
As a user I need a user name and password so that I can be confident my details remain private and I can access secure content Agent
Frequent Flyer
Repeat Traveler
Infrequent Vacation Planner User stories are collected and prioritized on a list called a product backlog What do I do with User Stories? 5 Step Process 1. Identify, clarify, and write down the business process being modeled No matter how much thinking,
thinking and thinking you do, you can't
completely specify a non-trivial system
up front. Software requirements is a
communication problem Those who want the software
must effectively communicate with
those who build it. A User Story Is Not... Not use cases
Not scenarios
Not IEEE 830 standard requirements
Not detailed requirements
Not design specs
Not artifacts of analysis, but user desired features in a system September 11, 2011 vs. September 18, 2011 vs. September 21, 2011 In a recent Wells Fargo survey, 74% of middle-class Americans
said they expect to work in their retirement years;
25% said they expect to work at least until age 80 Life Before Project Management 26 years before PERT Nearly 40 years before WBS 38 years before PMI 56 years before PMBOK The Empire State Building
was constructed in
one year and two months The original design was developed in two weeks could we match that achievement today? Life After Project Management Since the 1980's project management has undergone a major process of maturity 1969
Project Management Institute created 1984
First PMI certification exam 1987
First Project Management Body of Knowledge (PMBOK) 1990
Promulgation of Capability Maturity Model; PMI Membership less than 8,000 people; average of 55 people per year certified in 6 years 1996
First "Guide to the Project Management Body of Knowledge"; PMP certification has begun an exponential climb 2007
PMI membership stands at one-quarter million people; half million people have achieved certification since mid 1990's; 230,000 people are actively certified; "PMBOK Guide" is de facto world standard 2011
Agile certification available The 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: Right into coding vs. spending long weeks in analysis and design Types of meetings held quick, daily planning meetings vs. long, weekly status meetings Expectations of the team self-organized vs. directed Success -ful Principles Keys to Continuous improvement through time-boxed iterative deliveries and reviews Implementation of the most important items first Constant collaborative communication The requirements of the project should become stories in the agile team's backlog Use the Power of the Backlog Include stakeholders in the agile planning meetings Everyone understands what qualifies as barely sufficient deliverables, what assumptions the teams are making, and what dependencies exist. the "Barely Sufficient" Guideline "Barely Sufficient" philosophy should be applied in order to avoid doing more than absolutely necessary when faced with associated deliverables Is this something that we really must do? And if it is, then what is the simplest thing we can do to satisfy the need of the requestor? Follow up with the Five Whys, in trying to determine if the request is waste or truly needed. In the review and retrospective held at the end of each iteration, analyze the benefits and challenges you've just experienced Make recommendations on how to improve the experience in the next iteration Don't try to make too many changes at once. Focus on the items that can be easily fixed, and those that could potentially provide the biggest pain relief. Not Delivering as Promised Projects Top Reasons: Business Needs Changed No longer a priority Exceeding the budget $145b per year spent on failed and canceled projects Past Project Performance Record 40% of project spending is wasted as a result of rework 50% rolled back out of production 40% of problems found by end-users 70% project failures due to poor requirements gathering $30b+ per year U.S. business pay for project Loss: 41 - 7 Loss: 48 - 3 Objectives Agile Framework Characteristics Not a methodology Guiding Principles Business Users Needs Embraces Change Adapts to Environment Not "One Size Fits All" Umbrella Term Iterative-Incremental How the Burndown Chart Works On the first day of the sprint, August 1, the team estimated that there is approximately 70 story points/hours of work left to do. This was in effect the estimated velocity of the whole sprint.
On August 16 the team estimates that there is approximately 20 story points/hours of work left to do. The dashed trend line shows that they are approximately on track, i.e. at this pace they will complete everything by the end of the sprint. Guidelines 10 Terms to Remember Scrum Master
Product Owner
Sprint Backlog
Product Backlog Daily Scrum
Sprint Planning
Burndown Chart
User Stories
Delivery Team We Can Agree That... Emphasize verbal communication Stories shift the focus from writing to talking Comprehensible by both customer and developer Right size for planning Stories support and encourage iterative development Encourage deferring detail until you have the best understanding you want to Stories emphasize the user's goals not the systems attributes User Stories as a requirements process saves time, eliminates rework, and leads to better software A high level software system feature or requirement formulated as one sentence in the everyday language of the user A place holder for a conversation to be held later Written by the business or Product Owner Prioritized by the business with the help of the Product Owner to indicate which are most important for the system Detailed requirements for a User Story are gathered later, closer to when the story is actually implemented Must include acceptance/test criteria Can initially be large (called Epics) and broken down later Are simple, but they are not always easy User Story Format Start thinking of software as solving the needs of real people. Instead of "The User" think of specific roles like: A small set of stories are selected for delivery and only then are they broken down into detailed requirements Supporting the concept of "just in time" requirements Which One is the PM? Waterfall vs. Agile INVEST in User Stories Independent: A good story should stand on its own Negotiable: A good story is negotiable. It is not an explicit contract for features; rather, details are co-created by business and delivery teams during development. A good story captures the essence not the details. Valuable: A User Story should be valuable to the business. Estimable: The team should be able to gauge the size of a story Small: A good rule of thumb is that a User Story should be no more than a few person-weeks (or days) worth of work Testable: The story should include validation criteria Independent
Testable 2. Identify the actors involved in the business process 3. Brainstorm the actions each actor takes during the business process 4. Develop a use case diagram 5. Write user stories from the use case diagram Eat a meal at a restaurant As a Patron, I would like to order food As a Waiter, I would like to take an order from the Patron so the Chef can prepare the food As a Chef, I would like to prepare food for the order that was placed so it can be served to the Patron As a Cashier, I would like to accept payment for the food that was ordered and eaten As a Patron, I would like to eat the food that was served so I am no longer hungry As a Waiter, I would like to serve the prepared food to the Patron so they can eat it As a Patron, I would like to pay for the food I ordered and ate so I don't get arrested 1. Identify, clarify, and write down the business process being modeled 2. Identify the actors involved in the business process 4. Develop a use case diagram 5. Write user stories from the use case diagram 3. Brainstorm the actions each actor takes during the business process Why do your projects fail? Individuals and interactions
Working Software
Customer Collaboration
Responding to Change over process and tools over comprehensive documentation over contract negotiation over following a plan That is, while there is value in the items on
the right, we value the items on the left more." The expected deliverables chunks of working code early and often vs. documentation early with code at the end Patron Waiter Cashier Chef order food eat food pay for food pay for food order food serve food prepare food Patron Waiter Cashier Chef eat food pay for food order food serve food prepare food System Understand the fundamental working knowledge of Agile Scrum Experience an end-to-end Agile Scrum Project Have fun and be as passionate as people are with Fantasy Football Revenues at Disney are all about people how many visit the parks and how do they spend money while there When Robert Iger (CEO of Walt Disney Corporation) receives a daily report from his four theme parks near Orlando,
the report contains only two numbers: of yesterday’s attendance at the parks Forecast (Magic Kingdom, Epcot, Disney’s Animal Kingdom, Disney-MGM Studios, Typhoon Lagoon, and Blizzard Beach) AND Actual attendance An error close to zero is expected. Robert Iger takes his forecasts very seriously. Forecasts drive the work schedules of 58,000 cast members working at Walt Disney World Resort near Orlando. A daily forecast of attendance is made by adjusting Disney’s annual operating plan for weather forecasts, the previous day’s crowds, conventions, and seasonal variations. 20% With 20% of Walt Disney World Resort’s customers coming from outside the United States, its economic model includes such variables as gross domestic product (GDP), cross-exchange rates, and arrivals into the U.S. Disney also uses 35 analysts and 70 field people to survey 1 million people each year. The surveys, administered to guests at the parks and its 20 hotels, to employees, and to travel industry professionals, examine future travel plans and experiences at the parks. This helps forecast not only attendance but behavior at each ride (e.g., how long people will wait, how many times they will ride). Inputs to the monthly forecasting model include airline specials, speeches by the chair of the Federal Reserve, and Wall Street trends. Disney even monitors 3,000 school districts inside and outside the U.S. for holiday/vacation schedules. With this approach, Disney’s 5-year attendance forecast yields just a 5% error on average. Its annual forecasts have a 0% to 3% error. Attendance forecasts for the parks drive a whole slew of management decisions. For example, capacity on any day can be increased by opening at 8 a.m. instead of the usual 9 a.m., by opening more shows or rides, by adding more food/beverage carts (9 million hamburgers and 50 million Cokes are sold per year!), and by bringing in more employees (called “cast members”). Cast members are scheduled in 15-minute intervals throughout the parks for flexibility. Demand can be managed by limiting the number of guests admitted to the parks, with the “FAST PASS” reservation system, and by shifting crowds from rides to more street parades. forecasting is a key driver in the company’s success and competitive advantage. At Important Things First Simplest Thing that Works No Simpler and Follow Overlapping Phase Approach Detail requirements for User Stories
Created as Developed Adhere to Upfront Team Design Reviews and Backend Peer Code Reviews Document Code Religiously Leave Room for Successive Sprints
to Address New Features Co-location and War Rooms Test Case Reviews According to Plan Archers Paradox
Full transcript