Introduction to Agile Scrum

Transcription

1 Introduction to Agile Scrum by Julia M. Lobur Penn State Harrisburg CMPSC 487W Fall 2015 Introduction to Scrum Learning Goals Relationship of Scrum to other Agile methods Scrum Framework Scrum Roles Scrum Planning Sprint Execution Sprint Retrospective and Closure Scrum Anti-Patterns 1

2 Agile Manifesto Statement of Values Waterfall versus Iterative 2

3 Scrum as an Agile Process Agile is a framework to structure, plan, and control iterative and incremental development, where requirements and solutions evolve through collaboration between autonomous, crossfunctional teams. Scrum is the most popular Agile methodology. Others include: Crystal Methods (Crystal Clear) Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean software development Kanban (development) Key Scrum Concepts The focus is on delivering the highest business value in the shortest time. Working software delivered in increments (called sprints) every two weeks to one month. The business sets priorities. Teams self-organize to determine the best way to deliver the highest priority features. 3

4 Scrum vs. Waterfall Traditional project management emphasizes: Milestones Artifact ("deliverables") management Formal reporting Change control Scrum emphasizes: Iteration Incremental product delivery Transparency--project progress is reported and visible to all. User participation. 4

5 High-Level Scrum Framework Scrum Roles Scrum Roles Product Owner Prioritize the Product backlog Ensure project success Scrum Master Coach/Lead the Scrum team Ensure team effectiveness Scrum Team Small (5-9), self-directed team Cross-functional (BA, Dev, QA, DBA, UI, etc.) Multiple Scrum Teams (Scrum of Scrums) 5

6 Product Owner Responsible for product success Creates product vision Decides features in/out of scope Prioritizes in-scope features Approves feature changes Accepts/rejects work products Prioritize the Product backlog Ensure project success Represents concerns of product users Scrum Master Accountable to project manager Coaches team in Agile values and practices Removes impediments Ensures that the team is fully functional and productive Facilitates cross-functional cooperation Shields the team from external interferences 6

7 Scrum Team Typically 5-9 people Cross-functional: Programmers, testers, UX designers, etc. Membership varies as needed (e.g., DBA, training specialists, etc.) Membership should change only between sprints Teams are self-organizing Team determines content of each sprint No titles/rank (rarely possible in practice) High-Level Scrum Framework Scrum Ceremonies & Artifacts 7

8 Planning Large-Scale Agile Project Onion Diagram Scrum Planning 8

9 Product Planning Scrum Planning Scrum Planning 9

10 Scrum Planning 10

11 Release Planning : User Stories A user story is a high-level requirement statement It explains what the user expects from the system in order to achieve the user's business goal The idea is to provide just enough information so that effort estimation can be completed Each release consists of at least one user story usually many stories Release Planning : User Stories User story format: As a [role], I need to [execute feature] so that [business goal happens] The story must be testable and traceable! A story is a "lightweight" requirement The business goals of the system must be covered by all of the user stories. Watch for other functional requirements that do not come from the users! 11

12 INVEST Criteria for Good User Story I Independent: Self-contained - no dependencies on other stories N Negotiable: Until sprint begins stories can be changed V Valuable: Delivers value to the client E Estimable: You must be able to estimate effort required to realize a user story S Scalable (small sized): Small enough to plan and prioritize with some certainty T Testable: Sufficiently detailed to enable test development User Stories : Index Card Method 12

13 Release Planning : User Stories All user stories are collected and distributed to the team, or discussed in a team meeting. The team provides effort estimates using "story points." Story points are rough guesses of complexity produced using a Fibonacci sequence. Story Point Estimation 13

14 Release Planning Product owner collaborates with team Usually done within only a day or two Feature list (with corresponding user stories) is input for the effort, release plan is its output Using story point estimates, release is planned with customer focus and business goals in mind. Which features have immediate business value? What are the dependencies: business and technical? Timeframes are set User acceptance criteria are defined MoSCoW Prioritization M S C W Must have: Requirement that must be satisfied product to be considered a success. Should have: High-priority feature to be included if possible. Could have: Desirable but not necessary feature. Won't/Would have: Not be implemented in current release, consider for future release. "Feature Buffer" A Guide to the Business Analysis Body of Knowledge, v 2.0, sect

15 Release Planning Update the project timeline to reflect estimates based on user stories. Use the project start date, end date, sprint duration, and number of sprints. Sprint Planning For each sprint, a prioritized feature list (with user stories) is provided to team The team creates task lists from the user stories Team determines which tasks are to be included in the sprint The task must be small enough so that it can be completed with a 4 8 week sprint Tasks not selected for the sprint go on the backlog 15

16 Initially all items are in the backlog. This tool (Axosoft) distinguishes between "requested" and "approved" backlog items. Sprint Execution The scrum master leads daily standup team meetings Anyone can attend, including the project manager and project sponsor. Goal: Within 10 minutes (total!) every "committed" team member answers the following questions: What did you accomplish yesterday? What do you hope to accomplish today? What are the impediments preventing you form accomplishing today's task? 16

17 Sprint Execution Individuals sign up for work of their own choosing (work is never assigned) 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 Items are moved from the backlog to "development" to "complete." 17

18 The Scrum Development Cycle Sprint Execution Acceptance criteria for the sprint work items is established at the beginning of the sprint. "Definition of Done" (DoD) Should include user acceptance criteria and all appropriate documentation! At the end of each sprint, a sprint review or sprint retrospective takes place. [Formal] Review For only the stakeholders Retrospective For the team. 18

19 Sprint Retrospective Purpose is to improve team's effectiveness Entire team participates, perhaps even the stakeholders minutes What worked well during the sprint? What changes can be tried to make things better? Look for "quick wins" Attempt three or fewer changes Sprint Retrospective 1. If we were to do the sprint over, we would do these things the same. 2. If we were to do the sprint over, we would do these things differently. 3. What should we try next time? 19

20 Sprint Closure Update backlog Mark off completed items Add new items Reprioritize to include new items May need to rework project schedule!!! Update burndown chart indicates velocity Velocity: Amount of work removed from the backlog during each sprint. Plan next sprint Burndown Chart Total story points remaining in backlog Ideal or Estimated Velocity = Story Points per Iteration 20

21 Scrum Antipatterns Weak team or poor management Good team chemistry crucial to success Problems with team or its management will doom the project. If problem just in team, ask Scrum master to intervene. If problem with Scrum master, talk to project sponsor. Scrum Antipatterns Reverting to waterfall Usually caused by poorly executed scrum process. Sponsors or PM don't see results Project goes over time and budget Push heavyweight controls onto group Possible solution Look for outside expert to bring back on track Don't wait for sponsor or PM to raise the flags! The burndown chart is your friend! 21

22 Requirements creep Scrum Antipatterns As users use delivered software, requirements emerge: This is good. If sprints don't consistently result in a reduction of backlog items, you'll never get done. Possible solutions Reduce sprint duration Make sure backlog is reprioritized and costs assigned! Change freeze (as a last resort) Scrum Antipatterns Lack of documentation, or poor product performance Solution requires correct "definition of done." Suitable documentation must be part of acceptance criteria Build refactoring into schedule Make sure to require technical experts (e.g., QA staff and lead architect) to signoff on deliverables 22

23 Conclusion Scrum is a powerful Agile technique It is a disciplined process Must be well-managed Not suitable for all types of development effort Selected Scrum Books 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 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 User Stories Applied for Agile Software Development by Mike Cohn 23

24 Selected Scrum Sites Questions? 48 24