Agile Estimating Planning With Scrum, Kharkov

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

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

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

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

Agile Estimating Planning With Scrum, Kharkov

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Agile Estimating Planning With Scrum, Kharkov

Similar to Agile Estimating Planning With Scrum, Kharkov (20)

More from Alexey Krivitsky

More from Alexey Krivitsky (20)

Recently uploaded

Recently uploaded (20)

Agile Estimating Planning With Scrum, Kharkov