agile and scrum concepts for business · pdf filescrum framework 3 roles: – product...

Agile and Scrum Concepts for Business Analysts

Craig Fox Vice President, Senior Business AnalystBessemer Trust Certified Scrum Product Owner (CSPO)

@SR_BIZ_Analyst https://www.facebook.com/[email protected]

Views expressed in this presentation do not represent the views of Bessemer Trust.

Manifesto for Agile Software Development

2

Individuals and interactions Process and tools

Agile Manifesto Statement of Values

Over

Working software Comprehensive documentation Over

Customer Collaboration Contract negotiation Over

Responding to change Following a plan Over

Scrum Framework

3

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

Scrum Roles

Scrum Framework

5



Artifacts: – Epics, Stories, Spikes & Bugs – Product Backlog– Sprint Backlog– Burn Down Charts

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

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

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

External Team ResourcesExternal 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

Scrum Team Structure

10

Core

TechSpecialist

QA Analyst

Scrum Master

Business Analyst

Product Owner

Developer

Marketing

Legal

Manager

Business Sponsor

Info Security

Database Specialist

Architect

Focus Group Budget

Project Planning

Extended Team

Multi Team Projects

11

Agile Scrum Ceremonies

Scrum Framework

13



Artifacts: – Epics, Stories, Spikes & Bugs – Product Backlog– Sprint Backlog– Burn Down Charts

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

Daily ScrumAttendees – 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

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

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

Agile Scrum Artifacts

Scrum Framework

19



Artifacts: – Epics, Stories, Spikes & Bugs – Product Backlog– Sprint Backlog– Burn down Charts

Epics, Stories, Spikes and Bugs


21

Epics, Stories, Spikes and BugsEpics

▪ 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

22

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


23

User Stories

24

As a • specific

user/persona/role

I want • desired

feature/issue that needs to be solved

So that• benefit

from implementing the feature

+ Acceptance Criteria

User Stories – Estimation

25

User Stories - INVEST

26

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

Sprints

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

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

Sprint Backlog

31

Sequential vs. Overlapping Development

32

Rather than doing all of one thing at a time, Scrum teams do a little of everything all the time

Requirements Design Code Test

Source: “The New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

Sprint Cycle

33

Sprint Cycle

34

Sprint Cycle

35

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

36

ChangeChange

Change

Sprint Transparency

37

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.

38

X-Axis The project/iteration timelineY-Axis The work that needs to be completed for the project..

Project Start Point This is the farthest point to the left of the chart and occurs at day 0 of the project/iteration.

Project End PointThis is the point that is farthest to the right of the chart and occurs on the predicted last day of the project/iteration

Ideal Work Remaining Line

This is a straight line that connects the start point to the end point. At the start point,

Actual Work Remaining Line

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.

Agile-Scrum in Practice for Business Analysts

The Agile Business Analyst

Where is the business analyst most effective in Agile?

40

Product Owner

Scrum Team Scrum Master


The Business Analyst is a team member

41

Scrum Master

Product Owner

Team

Business Analyst


The Business Analyst is the Scrum Master

42

Business Analyst / Scrum Master

Product Owner

Team


The Business Analyst is the Product Owner

43

Scrum Master

Business Analyst / Product Owner

Team


The Business Analyst is the proxy Product Owner

44

Scrum Master

Business Analyst

Team

Product Owner

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 email?– 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

Are you truly Agile?

46

Agile In Action

47

Agile In Action

48

Craig Fox Vice President, Senior Business AnalystBessemer Trust Certified Scrum Product Owner (CSPO) Follow: @SR_BIZ_Analyst https://www.facebook.com/[email protected]

Mountain Goat Software, LLCPortions of the presentation were sourced from Mountain Goat Software LLC

agile and scrum concepts for business · pdf filescrum framework 3 roles: – product...

Documents