Agile Estimating and Planning With SCRUM: A Short Version of A Two-Day Class. Details Are Available at

Agile Estimating and Planning
with SCRUM
A short version of a two-day class.
Details are available at

www.scrumguides.com
Kharkov, 1 Feb 2008
© SCRUMguides
www.scrumguides.com
Alexey Krivitsky, Tim Yevgrashyn

Our Agenda
Introduction
10-minutes intro to SCRUM
Plans vs. Planning
Levels of Planning
User Stories as Agile Requirements
Release Planning in SCRUM
Sprint Planning in SCRUM

2 ©SCRUMguides
Who We Are
Ukrainian Agile community

www.agileukraine.org
SCRUM trainings and coaching

www.scrumguides.com
SCRUM Certifications (CSM)

www.scrum.com.ua

3 ©SCRUMguides
SCRUM
What’s in it for ya?
Who of you has been doing SCRUM?
Who of you is going to use SCRUM?
Who of you is never going to use it? ;)

4 ©SCRUMguides
What is this Training About?
Theory of project planning.

Different levels of project planning.
Agile techniques for size and estimations.
Agile techniques for duration estimations.
this all is presented under SCRUM jam

5 ©SCRUMguides
Our Ground Rules:
Can we all agree on this please?
No usage of laptops (pocket PCs, smart-phones)

yes we know how hard it is … ☺
Cell phones on silent mode
if you need to talk, please leave the class for a while
Be active, participate
use our knowledge and your time to maximize your returns
Don’t interrupt each other, one dialog per time
raise your hand if you wish to talk, the moderator will queue you up
Learn by asking questions
we promise to address all your questions
Thank You!
6 ©SCRUMguides
Levels of Learning
Level 1: Shu – learn the rules

“Do this, don’t do that”
Level 2: Ha – abide the rules

“You know how to do it one way, but there might be other ways.
Learn when to follow each”
Level 3: Ri – dissolve the rules

“I’m not sure how you call the way we work, we just get stuff done!”
This class is designed at Shu level with some Ha elements.

You can reach the next levels by practicing.

7 ©SCRUMguides
Our Agenda
Introduction
10-minutes intro to SCRUM 20 minutes :)
Plans vs. Planning
Levels of Planning

8 ©SCRUMguides
SCRUM in 100 words
SCRUM is a set of rules which are based on the Agile

principles which are designed to assist the customers and the
team to build constructive relationship.
Scrum is an agile process that allows us to focus on delivering

the highest business value in the shortest time (Mike Cohn).
Every two weeks to a month anyone can see real working

software and decide to release it as is or continue to enhance it
for another sprint (from SCRUM Framework).
SCRUM is about common sense (Ken Schwaber).

9 ©SCRUMguides
Origins of SCRUM
Jeff Sutherland
– Initial scrums at Easel Corp in 1993
– IDX and 500+ people doing Scrum
Ken Schwaber
– ADM
– Scrum presented at OOPSLA 96 with
Sutherland
– Author of three books on Scrum
Mike Beedle
– Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn
– Co-founded Scrum Alliance in 2002,
initially within the Agile Alliance

10 ©SCRUMguides
Characteristics
of SCRUM
One of the “agile processes”.

Self-organizing teams.
Delivers business functionality each 30 days
(two-weeks).
Requirements are captured and prioritized
throughout the project lifecycle.
No specific engineering practices prescribed.
Proven to be scalable for distributed teams, long
projects.
Simple but hard.

11 ©SCRUMguides
The Framework

12 ©SCRUMguides
SCRUM Terminology
ScrumMaster (SM) = Process Owner, Agile Manager
Product Owner (PO) = Customer Rep.
Sprint = Iteration
Product Backlog (PB) = Priotitized Inventory of

Requirements
Sprint Backlog (SP) = Task List

13 ©SCRUMguides
Principles of SCRUM
Common sense
Strict prioritization
Self-organizing team
Face-to-face communication
Frequent & regular delivery of whole system
Short feedback loop
Transparency
Time-boxing
Continuous improvement
Simple tools
Plans are needed, but they are always wrong
Common sense :)
From Henrik Kniberg’s “What is Scrum” Agile Estimating and Planning
14 http://crisp.se/ ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning 10 minutes
Levels of Planning

15 ©SCRUMguides
Referenced Materials
Mike Cohn’s Agile Estimating and Planning

User Stories Applied
Henrik Kniberg’s Scrum and XP from the Trenches

16 ©SCRUMguides
Why We Need Plans?
To predict the future
To memorize our expectation
To be able to compare our predictions we

made with the reality we are facing
To guide us to the desired situation/state

17 ©SCRUMguides
Usual Misunderstanding of Plans
A dialog you may have heard:
- Remember we agreed upon the plan and the

dates? How can you dare telling me now we
can’t make it?!
- …
- Have you seen this happening in your projects?

- Why this have happened?
- What can be the ways to avoid such situations?
18 ©SCRUMguides
Plans vs. Planning
If we value the knowledge…

If we agree that the future will likely be different
comparing to our predictions…
If we keep generating the new knowledge that
changes our understanding of the future AND the
future itself…
How can we at all believe to static plans?
Isn’t it limiting us?
Why don’t we just keep planning until we reach the
desired state or place or situation?
20 ©SCRUMguides
Famous Saying
“Plans are useless. Planning is vital.”

Eisenhower

21 ©SCRUMguides
Agile Planning
‘Ready… Fire… Aim… Aim… Aim… Aim…’
From Henrik Kniberg

22 ©SCRUMguides
Agile Planning
Planning (note the ‘-ing’) is happening through the life of an
agile project. There is no such a point in the project where the
plans got frozen and never updated anymore.
Nobody on the agile project can come to you and say:

“Hey, but we agreed you will be delivering 30 story points per
sprint. How can you be saying now you did only 20 because
you could not predict the flows in the technology? It is your job!
KABOOM!”
But don’t think of agile projects as blind activities without any

plans (some people do). We have plans, we just update them
as we learn new stuff. But why not? :)

23 ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning
Levels of Planning 10 minutes

24 ©SCRUMguides
The Three Levels of Planning
There are levels above

release planning, happening
within:
• strategic product line
management
• enterprise portfolio
management
We don’t touch these levels

as we want to look at the
levels happening in projects.
26 Each lower level supports the one above it. ©SCRUMguides
From Mike Cohn’s “Planning Agile Projects”

27 ©SCRUMguides

28 ©SCRUMguides
Planning is Negotiation
which ends when the plan is executed

29 ©SCRUMguides
The Goals of Release Planning
A time question:
How many iterations approximately will we need to deliver this rough
scope having the resources we might have?
Scope question:
How much of this rough product backlog can we do within this range of
sprints and having the resources we might have?
Resources question:
What resources do we need to accomplish this rough scope within this
range of sprints?
How rough can this be? What level of accuracy do we need?

What things do we need to know to make each of these predictions?

30 ©SCRUMguides
The Wrong Questions
…sometimes not questions at all
Can we deliver this list by 15.May next year?
Users will come in 5 months for a demo. We need to

deliver this 300 pages of requirements [full stop here]
Here’s your team, using this brand new

[insert any techno mambo-jambo here] technology you need to
deliver this stuff in 3 months. And don’t make me sad
because I trust you [exclamation mark]

31 ©SCRUMguides
The Goals of Iteration Planning
Duration is fixed.
Resources are fixed.

Why is it fixed?
Scope is open for discussions:

how many backlog items (stories) can we do during
the sprint?
What level of accuracy do we need here?

What we need to know to make the prediction?

32 ©SCRUMguides
The Goals of Daily Planning
Let’s discuss:
Why we need this planning?
How formal should this level of planning be?
Should you do it more often?
Why is this usually out of scope in project running by

a predictive process (e.g. waterfall)?

33 ©SCRUMguides
Exercise: A bad SCRUM meeting

34 ©SCRUMguides
So now you’ve learned that
There are different levels of planning.

Planning at each level has its own goal.
Each level has its own doers and
stakeholders.
Granularity and precision of plans differ at
the levels.
Formality of planning also vary.

35 ©SCRUMguides
From Henrik Kniberg’s “Scrum Introduction”
Granularity of Planning Details

36 ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning
Levels of Planning
User Stories as Agile Requirements 15 minutes

37 ©SCRUMguides
Terrifying Numbers
7 out of 10 IT projects “fail” in some respect. (OASIG study, 1995)
31.1% of projects will be canceled before they ever get

completed (Standish Group’s Chaos Report, 1995)
52.7% of projects will cost over 189% of their original estimates
Projects completed by the largest American companies have

only approximately 42% of the originally-proposed features

38 ©SCRUMguides
Why User Stories?
Our plans are based on users’ needs of systems that

we are building.
We know the needs are likely to be changing as we

will be proceeding.
It will add risks to our projects. The later the change

occur the higher the risks will be (more to rework).
That’s why we want the changes to occur

as early as possible, and as much as needed!
39 ©SCRUMguides
Think of Requirements
What are software requirements?
Some hints:
Stable vs. changing?
Known vs. emerging?
Based on knowledge vs. theories.
What is knowledge?
…
40 ©SCRUMguides
Why User Stories
A Special Tool
To satisfy the changing nature of the

users’ needs and our needs to still
being able to plan and track our
projects we need a special tool.

41 ©SCRUMguides
User Stories and Scrum
User stories naturally feet as items on a Scrum Product Backlog:

User Story Details
Use https for login page

As a normal user I can securely enter the site User enters email and password
Meeting data is: summary,
As a normal user I can enter new meetings details, datetime, place
As a normal user I can browse through my meetings Sort by datetime
As an admin I can manage the user list in order
to delete duplicate accounts
Simple text mailing is enough.
Support the templates:
As an admin I can mail selected users #email, #name, #date

43 ©SCRUMguides
What Makes Good User Stories?
Huh?

44 ©SCRUMguides
INVEST in Good User Stories
User Stories should be:
Independent
we should be able to prioritize different stories differently
Negotiable
think of stories as reminders for discussions to take place, never as contracts
Valuable
they should express value for end-users
Estimatable
since plans are based on stories we need to be able to estimate them
Sized appropriately
because complex stories are hard to estimate, compound stories are hard to
prioritize
Testable Agile Estimating and Planning

45 we need to know when each story is done ©SCRUMguides
A Good User Story Should …
Leave room for further discussions to provide flexibility.
Avoid specific UI aspects because they limit thinking and

creativity.
Be stated from a single user’s point of view and using single

voice to avoid any confusions.
Bring clear value to end-users, so that it can be prioritized (PO

is a business person). Stories should be written by people who
are as close to end-users as possible.
Contain hints on how it can be accepted to assert if it is done or

not.
46 ©SCRUMguides
Think of the Following User Stories
What’s Wrong with Them?
1. As a user I can search for books providing title, author, ISBN, year of
publishing, or a publisher. The search results are displayed 10 per a
page. If no books are found the user is taken to the main book catalog.
2. As a user I can type a city for search in an AJAX text-box 20 symbols

wide that is placed on top right of the “Search by Location” page with a
search button placed on the right of the text-box.
3. Users can delete their profiles.
4. The system should be designed with Spring MVC.
5. As a manager I can see team member list with block/activate

functionality whereas as a team member I can see the list in a read-
only mode only.
47 6. As a user I can get the book search results very fast.©SCRUMguides
Stories, Themes, Epics

48 ©SCRUMguides
Workshop
User Stories vs. ...
Software Requirement Specifications
Use-case Models
Task Lists

49 ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning
Levels of Planning
Release Planning in SCRUM 30 minutes

50 ©SCRUMguides
Release Planning
How many iterations?
How much scope?
At what costs?

51 ©SCRUMguides
Planning is Negotiations

52 ©SCRUMguides
Team Should Support Business
The teams should support the decision

makers by all possible means to enable
them to make the needed decisions.

53 ©SCRUMguides
How Long Will It Take … ?
To read a book?
To drive to another city?

54 ©SCRUMguides
From Mike Cohn’s “Agile Estimating and Planning”

55 ©SCRUMguides

56 ©SCRUMguides
Estimating in Story Points
Means the relative size of the story:
– Login screen is 2
– Search feature is 8
Unit-less points.
Integrated level of understanding, complexity, risks, feelings…
Precision is enough for release planning.
Easy to estimate, harder to explain.
Don’t inflate

57 ©SCRUMguides
Estimating in Ideal Time
Think of Ideal Time as when
– You have no interruptions
– You have all you need
– You feel good
Think of how many productive hours a day you usually have.
Hard to agree, easy to argue:

– I can do it in 10 hours, you can do it in 5. So who is right?
– Today I think it is 10h, next month (when I know more) I think it is 2
Easier to explain, harder to estimate.
Time estimates might inflate.

59 ©SCRUMguides

60 ©SCRUMguides
From Henrik Kniberg and Mike Cohn
Issues with Estimations

61 ©SCRUMguides
Issues with Estimations 2

62 ©SCRUMguides

63 ©SCRUMguides

64 ©SCRUMguides
Planning Poker
The Steps
Each estimator is given a deck of cards (1,2,3,5,8…)

A Product Owner reads a story
Estimators are for clarifications until everyone is ready to
estimate
Each estimator selects a card without showing it to the others
By command cards are got turned over
People with different estimates have discussions (limit with a
timer)
The round repeats until estimates converge

65 ©SCRUMguides
Planning Poker
It Helps to Avoid the Pitfalls
Uses the right units
Avoids anchoring
Implies negotiating
Everyone is listened
It’s quick and fun! :)

66 ©SCRUMguides

67 ©SCRUMguides
Velocity
A speed at which the team is able to convert

product backlog items into working product.

68 ©SCRUMguides

69 ©SCRUMguides

70 ©SCRUMguides

71 ©SCRUMguides
From Henrik Kniberg
Calibrating Velocity

72 ©SCRUMguides
Visualizing Release Planning
Release Burndown
350
320
300
275
Backlog Size
250
220
200
150
100 90
50 40
0 0
1 2 3 4 5 6
Sprints Agile Estimating and Planning
73 ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning
Levels of Planning
Sprint Planning in SCRUM 20 minutes

74 ©SCRUMguides
Iteration Planning

75 ©SCRUMguides
Iteration Planning
Contains of two parts:
1. Select the top PB items for the sprint

PO’s involvement is mandatory
2. Team builds the task list

with original estimates in hours and assignments

76 ©SCRUMguides
Iteration Planning
Inputs
Initial sprint goal

(can be changed during the planning)
Team’s velocity
(averaged or estimated)
Team members’ availability over the next sprint
(think of holidays, planned day-offs, vacations, conferences and
trainings, changes in the team)
PB with estimates
(at least for the top items for the next 2-3 sprints)
Outcomes from the last sprint review and
retrospective
77 ©SCRUMguides
Iteration Planning
Outputs
Updated sprint goal the Team (all members) is

committed to.
A set of top PB items (with agreed accepting
criterions) the Team believes they can convert into
working product during the sprint.
Agreed upon a date and time of the review meeting.
Sprint Backlog (SB) with initial assignments and
rough estimates in hours done by the team.
Agreement with the stakeholders on the level of
visibility the team will be providing (makes sense for
distributed development).
78 ©SCRUMguides
Iteration Planning
Strategy Based on Commitments
1. The Team and the PO go from the top of the PB discussing

each item.
2. Upon the discussion the Team may ask any question that
might affects estimate and acceptance of the item until
everyone agrees on the strategy of the implementation and
ready to estimate it.
3. When everyone agrees with the estimate and the acceptance
criterion, a team member self-commits to become
responsible for the item. Absent people cannot become
responsible for any items.
4. The name of the responsible person is recorded in the PB and
the next item is pulled out for discussion.
5. This process continues until no-one can self-commit for the
next item.
79 ©SCRUMguides
Talk SCRUM
We need 3 potential POs

We need 3 potential SMs
We need 3 potential team members

80 ©SCRUMguides
Our Agenda
Introduction
Plans vs. Planning
Levels of Planning
Questions

81 ©SCRUMguides

Agile Estimating and Planning With SCRUM: A Short Version of A Two-Day Class. Details Are Available at

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Agile Estimating and Planning With SCRUM: A Short Version of A Two-Day Class. Details Are Available at

Încărcat de

Drepturi de autor:

Formate disponibile

Agile Estimating and Planning

A short version of a two-day class.

Details are available at

Kharkov, 1 Feb 2008

Alexey Krivitsky, Tim Yevgrashyn

10-minutes intro to SCRUM

Plans vs. Planning

User Stories as Agile Requirements

Release Planning in SCRUM

Sprint Planning in SCRUM