Agile EstimationStephen ForteChief Strategy OfficerTelerikSession Code: DEV317

BioChief Strategy Officer of TelerikCertified Scrum MasterActive in the Community:

International Conference Speaker for 12+ YearsRD, MVP and INETA Speaker Co-moderator & founder of NYC .NET Developers Group http://www.nycdotnetdev.comWrote a few books: SQL Server 2008 Developers Guide (MS Press)

MBA from the City University of New YorkPast:

CTO and co-Founder of Corzen, Inc. (TXV: WAN)CTO of Zagat Survey

Agenda

The Estimation ProblemAgile EstimationToolsQ&A

Agenda

The Estimation ProblemAgile EstimationTools Q&A

Estimation

Wikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.

Problem is that estimates become a unbreakable schedule, where any deviation is considered bad

Problem #1 with Estimates

Estimate for our project:1 month for design and architecture4 months for development 1 month for testing

Scenario:Your first estimate is wrong by 1 week (design)What do you do?

The Estimation Problem

When you come up with a project idea, your first estimate is off by +/ 4x

Not enough details are knownTraditionally too much time is spent on building a specification which is not complete

Again, not enough details are knownAs time progresses, more details emerge about the system and its details

The cone of uncertainty

The Cone of Uncertainty

Real life storyFrom Zagat.com in .com boomProject was “late” due to no re-estimation and emerging requirementsDaily status meeting with CEO on the MS Project planPatrick has 5 tasks for this week, each estimated for 1 day each

Patrick comes to you and says I am going to spend 3 days writing a code gen utility and one day testing it then on Friday, all of my tasks will be done with a button push

Try explaining that to the CEO!

Agenda

The Estimation ProblemAgile EstimationToolsQ&A

Agile Estimation

Wikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.

Problem is that estimates become a unbreakable schedule, where any deviation is considered bad

Agile Estimation throws this logic away and always re-estimates a project after each iteration

Different value system, deviations are not deviations, they are more accurate estimationsUses the cone of uncertainty to your advantage

How to Estimate

User StoriesPlanning PokerStory PointsProduct BacklogVelocityRe-estimation

User Stories

Users break down the functionality into “User Stories”User Stories are kept smallUser Stories include acceptance criteria

Planning Poker

After all the user stories are written, get a list of stories and do a high level estimate

Estimate is for setting priorities, not scheduleNOT a time based estimation

Super hard, Hard, Medium, Easy, Super easyDone by consensus

To get there you play planning pokerWhy? No pressure.

Story Points

Break down user stories to units of relative size So you can compare featuresAlternative to time

Story Points are not a measurement of duration, but rather a measurement of size/complexityStart with 1 standard feature and then other features are either 1x, 2x, etc larger or smaller than that relative feature in size/complexity

Product Backlog

All story points are put into a bucketThis represents all of the tasks for the project (work items)Backlog will have an item and its estimate

Remember this estimate is not time based, but point based

Backlog can also contain the priority

A sample product backlogBacklog item Estimate

Allow a guest to make a reservation 3

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8

Improve exception handling 8... 30... 50

Sprint 1

Developers will commit to XX story pointsWarning, they will usually over commitAfter the end of sprint 1, you have your first velocity number

Team Velocity

Velocity is the number of story points per sprint completedYou calculate velocity to predict how much work to commit to in a sprintVelocity only works if you estimate your story points consistency Over time you will know: team has a velocity of 32 story points per sprint

Over time this will self-correctOver time you will be able to predict the project schedule (and release)

Calculating Team Velocity

Select a regular time period (sprint) over which to measure VelocityAdd up the story point estimates 100% completedAt the end of the sprint, the figure you have is your VelocityYou can then use your Velocity as a basis for your future commitments

Velocity Charts

True way to see the health of a project

Re-estimation

As you complete more sprints, your velocity will change

Velocity changes because of minor inconsistencies in the story point estimatesTeam velocity will typically stabilize between 3 and 6 iterations

Re-estimation of the entire project happens after each sprint

New VelocityNew story points added and removed (completed)Use the cone!

Agenda

The Estimation ProblemAgile EstimationToolsQ&A

Tons of Tools

I prefer user stories to be on paperCan transcribe to ExcelDo NOT create VSTS work items until you have all of the user stories estimated

Visual Studio Team System

Scrum templatesStory points become work items

Agenda

The Estimation ProblemAgile EstimationToolsQ&A

Reading List

Books I have read and recommend:User Stories Applied by Mike CohnAgile Estimating and Planning by Mike CohnAgile Retrospectives by Esther Derby and Diana Larsen

question & answer

www.microsoft.com/teched Sessions On-Demand &

Community

http://microsoft.com/technet

Resources for IT Professionals

http://microsoft.com/msdn

Resources for Developers

www.microsoft.com/learning Microsoft Certification & Training

Resources

Resources

Complete an evaluation on

CommNet and enter to win an Xbox 360

Elite!

© 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it

should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.