Agile and Scrum Concepts for Business Analysts

Transcription

1 Agile and Scrum Concepts for Business Analysts Craig Fox Vice President, Senior Business Analyst Bessemer Trust Certified Scrum Product Owner Views expressed in this presentation do not represent the views of Bessemer Trust.

2 Manifesto for Agile Software Development Agile Manifesto Statement of Values Individuals and interactions Over Process and tools Working software Over Comprehensive documentation Customer Collaboration Over Contract negotiation Responding to change Over Following a plan 2

3 Scrum Framework Roles: Product Owner Scrum Master Team Member External Resources Ceremonies: Sprint Planning Daily Scrum Meeting Sprint Review Sprint Retrospective Artifacts: Epics, Stories, Spikes & Bugs Product Backlog Sprint Backlog Burn-Down Charts 3

4 Scrum Roles

5 Scrum Framework Roles: Product Owner Scrum Master Team Member External Resources Ceremonies: Sprint Planning Daily Scrum Meeting Sprint Review Sprint Retrospective Artifacts: Epics, Stories, Spikes & Bugs Product Backlog Sprint Backlog Burn Down Charts 5

6 Product Owner Product Owner: Owns the backlog (requirements) Works with the business to prioritizes the backlog to provide high value first Creates Epics, User Stories, Tech Stories with testable acceptance criteria Should have a deep understanding of the business and technology Makes sure everyone on the team and the business is involved Release Planning Holds the following Scrum meetings: Back log refinement (estimation and prioritization) Sprint Planning 6

7 Scrum Master Scrum Master: Makes sure everyone on the team is following the Scrum Process Removes obstacles, coordinates dependencies (non-team resources, vacations, skill gaps, etc.) Holds the following Scrum meetings: Daily Scrum meetings Sprint Review / Sprint Closing Retrospective 7

8 Team Member Team Members: Cross Functional team that is responsible for delivering the work May contain: Product Owner and Scrum Master Business Analysts Developers Quality Assurance Database Specialists Server engineers Network administrators Application Architects Automation Engineers Information Security Analyst 8

9 External Team Resources External Team Members: Cross Functional team that is responsible for delivering work but is not part of the Scrum team and is not involved daily May contain: Business units Stakeholders Marketing Legal Compliance Database Specialists Data operations Automation Engineers Server engineers Network administrators Application Architects Information Security Analyst 9

10 Scrum Team Structure Business Sponsor Tech Specialist Marketing Extended Team Info Security Developer Legal Database Specialist Product Owner Core Scrum Master Manager Business Analyst QA Analyst Architect Project Planning Focus Group Budget 10

11 Multi Team Projects 11

12 Agile Scrum Ceremonies

13 Scrum Framework Roles: Product Owner Scrum Master Team Member External Resources Ceremonies: Sprint Planning Daily Scrum Meeting Sprint Review Sprint Retrospective Artifacts: Epics, Stories, Spikes & Bugs Product Backlog Sprint Backlog Burn Down Charts 13

14 Sprint Planning Attendees Core scrum team only The Scrum Master ensures that the event takes place The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. The Scrum Master teaches the Scrum Team to keep it within the time-box. Sprint Planning answers the following: What can be delivered in the Increment resulting from the upcoming Sprint? How will the work needed to deliver the Increment be achieved? 14

15 Daily Scrum Attendees Core scrum team only The Scrum Master ensures that the event takes place. The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain: Answer three questions What did I do yesterday that helped the Development Team meet the Sprint Goal? What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediment that prevents me or the Development Team from meeting the Goal? 15

16 Sprint Review Attendees Scrum Team and anyone with interest (management, stakeholders, sponsors) The Product Owner ensures that the event takes place A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. Attendees include the Scrum Team and key stakeholders invited by the Product Owner The Product Owner explains what Product Backlog items have been Done and what has not been Done The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved The Development Team demonstrates the work that it has Done and answers questions about the Increment The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed) The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning; Review of what is the most valuable items to do next Review of the timeline, budget, and potential capabilities anticipated in the next release. 16

17 Sprint Retrospective Attendees Core scrum team only The Scrum Master ensures that the event takes place The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. The Scrum Master keeps within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process. The purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work. The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of Done as appropriate. 17

18 Agile Scrum Artifacts

19 Scrum Framework Roles: Product Owner Scrum Master Team Member External Resources Ceremonies: Sprint Planning Daily Scrum Meeting Sprint Review Sprint Retrospective Artifacts: Epics, Stories, Spikes & Bugs Product Backlog Sprint Backlog Burn down Charts 19

20 Epics, Stories, Spikes and Bugs

21 Epics, Stories, Spikes and Bugs 21

22 Epics, Stories, Spikes and Bugs Epics An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic Example Building the checkout function on a shopping website BUGS A bug is created and added to the backlog if it cannot be resolved in the same sprint or is found at a later date User Stories /Tech Stories A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement User Stories form the individual pieces of work that make up the project and sprint backlog Spikes A story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a spike, which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog 22

23 Epics, Stories, Spikes and Bugs 23

24 User Stories As a specific user/ persona/ role I want desired feature/ issue that needs to be solved So that benefit from implementi ng the feature + Acceptance Criteria 24

25 User Stories Estimation 25

26 User Stories - INVEST 26

27 Product Backlog In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items When the sprint planning meeting occurs, the Scrum team converses with the Product Owner to determine what work they will tackle in the impending iteration. At this time, the Product Owner imports product backlog items into the sprint backlog. 27

28 Sprints

29 Sprint Backlog During the sprint planning meeting, the team selects some number of product backlog items for consideration to be completed in the next sprint The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. Each sprint should have a clearly defined goal that everyone can contribute to achieving that goal. 29

30 Sprints Scrum projects make progress in a series of sprints The first act of a new sprint is to have a sprint planning meeting The sprint should contain the most important items in the backlog that are ready A new sprint begins immediately following the end of the previous sprint At sprint planning, stories are moved from the product backlog to the sprint backlog Typical duration is 2 4 weeks or a calendar month at most A constant duration leads to a better rhythm Sprint backlog items are designed, coded, and tested during the sprint 30

31 Sprint Backlog 31

32 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 Product Development Game by Takeuchi and Nonaka. Harvard Business Review, January

33 Sprint Cycle 33

34 Sprint Cycle 34

35 Sprint Cycle 35

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

37 Sprint Transparency 37

38 Burn down Charts A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run hart of outstanding work. It is useful for predicting when all of the work will be completed. X-Axis Y-Axis Project Start Point Project End Point Ideal Work Remaining Line Actual Work Remaining Line The project/iteration timeline The work that needs to be completed for the project.. This is the farthest point to the left of the chart and occurs at day 0 of the project/iteration. This is the point that is farthest to the right of the chart and occurs on the predicted last day of the project/ iteration This is a straight line that connects the start point to the end point. At the start point, This shows the actual work remaining. At the start point, the actual work remaining is the same as the ideal work remaining but as time progresses, the actual work line fluctuates above and below the ideal line depending on how effective the team is. 38

39 Agile-Scrum in Practice for Business Analysts

40 The Agile Business Analyst Where is the business analyst most effective in Agile? Product Owner Scrum Master Scrum Team 40

41 The Agile Business Analyst The Business Analyst is a team member Scrum Master Business Analyst Team Product Owner 41

42 The Agile Business Analyst The Business Analyst is the Scrum Master Business Analyst / Scrum Master Team Product Owner 42

43 The Agile Business Analyst The Business Analyst is the Product Owner Scrum Master Team Business Analyst / Product Owner 43

44 The Agile Business Analyst The Business Analyst is the proxy Product Owner Scrum Master Product Owner Team Business Analyst 44

45 Are you truly Agile? Does what we re doing at this moment support the early and continuous delivery of valuable software? Does our process welcome change and take advantage of change? Does our process lead to and support the delivery of working software? Are the developers and the product owner working together daily? Are customer and business stakeholders working closely with the project team? Does our environment give the development team the support it needs to get the job done? Are we communicating face-to-face more than through phone call and ? Are we measuring progress by the amount of working software produced? Can we maintain this pace indefinitely? Do we support technical excellence and good design that allows for future changes? Are we maximizing the amount of work not done- namely, doing as little as necessary to fulfill the goal of the project? Is this development team self-organizing and self-managing? Does it have the freedom to succeed? Are we reflecting at regular intervals and adjusting our behavior accordingly? If you answered, yes to all of these questions, congratulations; you are truly working on an agile project. 45

46 Are you truly Agile? 46

47 Agile In Action 47

48 Agile In Action 48

49 Craig Fox Vice President, Senior Business Analyst Bessemer Trust Certified Scrum Product Owner (CSPO) Mountain Goat Software, LLC Portions of the presentation were sourced from Mountain Goat Software LLC