So why SCRUM?

Ciprian Sorlea, Development Manager

September 2013

2

A real life story

October 2007, USAOctober 2007

The Customer had an Idea,

and wanted to build a Product.

3

A real life story

November 2007

The Customer has identified

the right Consultant to

implement his Product.

4

A real life story

May 2008

The Customer and the Consultant

have built the Documentation &

Requirements, so they should be

ready for implementing (by us).

5

A real life story

June 2008

The Development Team

evaluated the

Requirements and they

came up with the

Estimates.

6

A real life story

July 2008

The Customer and the Consultant decide to rebuild the requirements:

- To be able to cut the cost of development with 30% due to the budget limitations

- To be able to accommodate the new market demands + new ideas

7

A real life story

December 2008

The updated requirements

are ready. This time, twice

as “complete”. It’s time to

start re-evaluating the

estimates.

8

A real life story

January 2009

With the updated estimates approved, we’re ready to start doing the WORK.

It’s only been 16 months since the Customer had the Idea.

9

A real life story

April 2009

The Consultant shows the

end result to the Customer.

The Customer realizes the

mistakes and…

10

A real life story

… fires the Consultant and

decides to work directly

with the Development

Team.

11

A real life story

Summary of phase 1:

- Idea to product: 20 months

- Customer satisfaction: almost 0% (time wasted,

features not how the customer envisioned, etc.).

- ROI: almost 0, as the product is already behind the

market

12

A real life story

Other problems in phase 1:

- Developers had many ideas, but because of the

contract & estimates, they had to stick to the requirements

- Estimates were highly inaccurate due to the unknown

business requirements and some undocumented dependencies,

plus all the other issues that “came up”

- Developers were frustrated because their product was

nowhere to see (can’t brag about to their fellow developers)

13

A real life story

The profit made by the Development Company:

10% of the contract value

14

A real life story

15

A real life story

In phase 2, we decided to make some

slight adjustments to the process

16

A real life story

We started with just enough

documentation:

- The vision & value

proposition

- Some mockups

- High level description of

the

features

17

A real life story

We brainstormed with the customer, analyzed all requirements and we put a bunch of ideas on the wall.

Including our own ideas.

Including some ideas that would never make it into the product.

18

A real life story

The customer then analyzed all important ideas and assigned them a value. A business value.

We evaluated the ideas and assigned them a rank, so that we know which are the most complex, and which ones are easy to do.

19

A real life story

We sorted the items on the wall based on their contribution to the ROI(their value) and the complexity.

The ones that were easy to do and could bring a lot of value were always first.

20

A real life story

We estimated how much we could do before we could showthe result of our work to the customer (2 weeks) and we picked what we’ll deliver at the end of the 2 weeks period, as a team.

We had daily short meetings to see if we are on the track with our progress, if anybody has any issues so that the team can step in and help.

21

A real life story

We demoed the completed features to the customer at the end of the period, and collected feedback.

We talked after each demo and identified few things that could help us be a better team.

22

A real life story

Every week we removedsome of the ideas from the wall, as they didn’t made sense anymore.

Or we added new ones.

We were happy to changeanything on the wall, because we knew it’s making OURproduct better

23

A real life story

We continuouslyexpressed our ideas and helped the customer find easier and faster solutions to some of his needs.

This helped the customer save money while getting a better product and it helped us to do interesting things.

24

A real life story

And we repeated this several times (about 5 times – so for two months and a half), till the client said:

“I’m happy with what I have so far. Everything else that we had on the requirements, I think my customers will never need.”

25

A real life story

Summary of phase 2:

- Idea to product: 3 months

- Customer satisfaction: 100%. Not only the customer got what he wanted, he got more, for less than the expected investment.

- ROI: very high, as the customer started making money from some beta subscriptions since the 3’rd iteration.

26

A real life story

The profit made by the Development Company:

70% of the initial contract value

27

A real life story

So what are we looking at?

Where is SCRUM in this story?

29

The SCRUM Framework

30

SCRUM - Roles & Responsibilities

- Product Owner: maximizes the business value delivered by the team, by setting the right priorities and defining enough information

- Scrum Master: a servant leader who helps everybody follow the process and helps the PO to keep the backlog in good shape. Removes impediments from the team.

- The Team: self organize themselves to deliver the WORK in the most efficient way

31

SCRUM - Artifacts

- Product Backlog

- Sprint Backlog

- Burndown Chart

- Product Increment

- Impediments Backlog

32

SCRUM - Product Backlog

- A prioritized features list

- Anybody can contribute (including stakeholders)

- Can only be prioritized by the Product Owner

- Priorities can change at any time, depending on the

dynamic of the business

- Content can be changed at any time

- Can contain User Stories, Epics or Themes

33

SCRUM - User Stories

- "As a <role>, I want <goal/desire> so that <benefit>“

- Focused on personas/actors/roles

- Must be achievable during a single iteration

- Each story must generate value (Business Value):

- Return Of Investment: $$$

- Customer Satisfaction: eventually translates into $$$

34

SCRUM - Epics

- More than a story, but not the whole book

- Can group multiple stories that are part of the same feature

- Can group multiple stories that represent the functionalities split among various roles or actors of the system

- Can group multiple stories that belong to the same feature across various components

- Represents the mid term plans, and will require further details, clarifications and breakdown

35

SCRUM - Themes

- Represents Long term plans

- Will eventually be broken down into related stories

and or epics

36

SCRUM - Backlog prioritization

- Each story should have a

Business Value assigned

- Each story should have an

estimate (Story Point)

- Both estimates could be

made using planning poker

- The R factor (BV/SP) allows

accurate prioritization

37

SCRUM - Story Point

- An arbitrary measure of complexity for Stories,

meant to be used as a scale for comparing stories

(comparing all stories to a baseline)

- Can use Tshirt Sizing (XS, S, M, L, XL)

- Can use the Fibonacci sequence (1,2,3,5,8,13, etc)

- Usually established through poker planning

- Stimulates the communication and collaboration

to reveal facts and details about stories

38

SCRUM - Sprint Backlog

- A list of refined and detailed enough user stories

- All stories picked should be Ready Ready

- Picked by the team to be implemented during the sprint

- It reflects the team forecast and commitment towards

what will be completed

- It’s still sorted based on PO set priorities.

- The team can help the PO to adjust the priorities to

reflect some dependencies between stories

39

SCRUM - Burndown Chart

40

SCRUM - Burndown Chart

- A visual representation of the progress of the team towards the completion of the work in the sprint

- Can be used to predict the completion or to identify the bottlenecks as they occur

- Should be updated real time (when tasks are completed, or when a new evaluation is available - remaining effort)

- Can be based on hours (tasks), number of tasks or number of stories remaining

- Focus is on remaining effort needed to get all things done

41

SCRUM - Product increment

- It’s the outcome of the team’s work during the sprint

- Contains all the demoed and PO accepted user stories

- All stories within the increment must be Done-Done

- Should constantly deliver Business Value

- It should be Production Ready

42

SCRUM - Impediments Backlog

- A list of issues that prevents the Team to perform as

they would want to

- The list is based on the feedback from the Team

- It is prioritized by the team

- It has action items associated

- The Scrum Master collects the backlog

- The Scrum Master follows up with the responsible of

each action item

43

SCRUM - Activities

44

SCRUM - Other Activities

- Product Planning

- Release Planning

- Backlog Grooming

- Mid Sprint Review

- Detailed Sprint Planning / Task Breakdown

45

SCRUM - Ready Ready

- Defines the level of information needed for each story before they are considered ready for development

- Ex:

- Contains the mockups

- Defines the acceptance criteria

- Defines the non functional requirements (security, performance, etc)

- Might be different depending on story/issue type (ex. defect, escalation, etc)

46

SCRUM - Definition of Done

- Defines when the story is Done Done (aka ready for production and PO acceptance)

- Contains what the Team along with PO expect and commit to deliver with each story

- Ex:

- Documentation - Code Review

- Unit tests passed - QA Acceptance

- Continuous Integration - End To End Integration passed

- Performance tests - Demo Scripts & Recorded Demos

So how do we get SCRUM to work for us?

48

The SCRUM Principles

49

The Agile Manifesto

○ Individuals and interactions over processes and tools

○ Working software over comprehensive documentation

○ Customer collaboration over contract negotiation

○ Responding to change over following a plan

50

The SCRUM values

○ FOCUS

○ COURAGE

○ OPENESS

○ COMMITMENT

○ RESPECT

51

To make it work

○ Let SCRUM do its work

○ Understand the core framework before trying to change it /

adapt it

○ Follow the principles

○ Respect the values

○ Don’t try shortcuts (SCRUMBUT)

52

To make it work

○ Work as A TEAM

Thanks for watching.Now go have some fun, with SCRUM!