�ݺ�ߣ

So why SCRUM?
Ciprian Sorlea, Development Manager
September 2013

2
A real life story
October 2007, USA
October 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

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 show
the 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 removed
some of the ideas from the
wall, as they didn’t made
sense anymore.
Or we added new ones.
We were happy to change
anything on the wall, because
we knew it’s making OUR
product better

23
A real life story
We continuously
expressed 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

So what are we looking at?
Where is SCRUM in this story?

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

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

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?

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!

�ݺ�ߣ

Why scrum

Recommended

More Related Content

Similar to Why scrum (20)

Recently uploaded (20)

Why scrum