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

© SCRUMguideswww.scrumguides.com

Alexey Krivitsky, Tim Yevgrashyn

Kharkov, 1 Feb 2008

Agile Estimating and Planning ©SCRUMguides2

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


Who We Are

Ukrainian Agile communitywww.agileukraine.org

SCRUM trainings and coachingwww.scrumguides.com

SCRUM Certifications (CSM)www.scrum.com.ua


SCRUMWhat’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? ;)


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


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 modeif you need to talk, please leave the class for a whileBe active, participateuse our knowledge and your time to maximize your returnsDon’t interrupt each other, one dialog per timeraise your hand if you wish to talk, the moderator will queue you upLearn by asking questionswe promise to address all your questions

Thank You!


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.


Our Agenda

Introduction

10-minutes intro to SCRUM 20 minutes :)

Plans vs. Planning

Levels of Planning





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).


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

Origins of SCRUM


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.


The Framework


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


Principles of SCRUM

Common senseStrict prioritizationSelf-organizing teamFace-to-face communicationFrequent & regular delivery of whole systemShort feedback loopTransparencyTime-boxingContinuous improvementSimple toolsPlans are needed, but they are always wrongCommon sense :)

From Henrik Kniberg’s “What is Scrum”http://crisp.se/


Our Agenda

Introduction


Plans vs. Planning 10 minutes

Levels of Planning





Referenced Materials

Mike Cohn’s Agile Estimating and PlanningUser Stories Applied

Henrik Kniberg’s Scrum and XP from the Trenches


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


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?


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?


Famous Saying

“Plans are useless. Planning is vital.”Eisenhower


Agile Planning‘Ready… Fire… Aim… Aim… Aim… Aim…’

From Henrik Kniberg


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 theplans 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? :)


Our Agenda

Introduction


Plans vs. Planning

Levels of Planning 10 minutes





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.

Each lower level supports the one above it.


From Mike Cohn’s “Planning Agile Projects”




Planning is Negotiation which ends when the plan is executed


The Goals of Release Planning

A time question: How many iterations approximately will we need to deliver this roughscope 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?


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]


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?


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)?


Exercise: A bad SCRUM meeting


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.


Granularity of Planning Details

From Henrik Kniberg’s “Scrum Introduction”


Our Agenda

Introduction


Plans vs. Planning

Levels of Planning

User Stories as Agile Requirements 15 minutes




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


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!


Think of Requirements

What are software requirements?

Some hints:Stable vs. changing?Known vs. emerging?Based on knowledge vs. theories. What is knowledge?…


Why User StoriesA 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.


User Stories and Scrum

User stories naturally feet as items on a Scrum Product Backlog:

User Story Details

As a normal user I can securely enter the siteUse https for login page User enters email and password

As a normal user I can enter new meetingsMeeting data is: summary, details, datetime, place

As a normal user I can browse through my meetings Sort by datetimeAs an admin I can manage the user list in order to delete duplicate accounts

As an admin I can mail selected users

Simple text mailing is enough.Support the templates: #email, #name, #date


What Makes Good User Stories?

Huh?


User Stories should be:Independentwe should be able to prioritize different stories differently

Negotiablethink of stories as reminders for discussions to take place, never as contracts

Valuablethey should express value for end-users

Estimatablesince plans are based on stories we need to be able to estimate them

Sized appropriatelybecause complex stories are hard to estimate, compound stories are hard to prioritize

Testablewe need to know when each story is done

INVEST in Good User Stories


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.


Think of the Following User StoriesWhat’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.

6. As a user I can get the book search results very fast.


Stories, Themes, Epics



WorkshopUser Stories vs. ...

Software Requirement Specifications

Use-case Models

Task Lists

…


Our Agenda

Introduction


Plans vs. Planning

Levels of Planning


Release Planning in SCRUM 30 minutes



Release Planning

How many iterations?

How much scope?

At what costs?


Planning is Negotiations


Team Should Support Business

The teams should support the decision makers by all possible means to enable them to make the needed decisions.


How Long Will It Take … ?

To read a book?

To drive to another city?


From Mike Cohn’s “Agile Estimating and Planning”




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


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.




Issues with Estimations

From Henrik Kniberg and Mike Cohn


Issues with Estimations 2









Planning PokerThe Steps

Each estimator is given a deck of cards (1,2,3,5,8…)A Product Owner reads a storyEstimators are for clarifications until everyone is ready to estimateEach estimator selects a card without showing it to the othersBy command cards are got turned overPeople with different estimates have discussions (limit with a timer)The round repeats until estimates converge


Planning Poker It Helps to Avoid the Pitfalls

Uses the right units

Avoids anchoring

Implies negotiating

Everyone is listened

It’s quick and fun! :)




Velocity

A speed at which the team is able to convert product backlog items into working product.








Calibrating Velocity

From Henrik Kniberg


Visualizing Release Planning

Release Burndown

320275

220

9040

0050

100150200250

300350

1 2 3 4 5 6

Sprints

Bac

klog

Siz

e


Our Agenda

Introduction


Plans vs. Planning

Levels of Planning



Sprint Planning in SCRUM 20 minutes


Iteration Planning



Iteration Planning

Contains of two parts:

1. Select the top PB items for the sprintPO’s involvement is mandatory

2. Team builds the task list with original estimates in hours and assignments


Iteration PlanningInputs

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


Iteration PlanningOutputs

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).


Iteration PlanningStrategy 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.


Talk SCRUM

We need 3 potential POsWe need 3 potential SMsWe need 3 potential team members


Our AgendaIntroduction


Plans vs. Planning

Levels of Planning




Questions

Technology

Agile Estimating Planning With Scrum, Kharkov