2-2 Estimating Size in Ideal Days

Outline Ideal vs. elapsed time Ideal time as an estimate of size Comparison between story points and ideal days

Ideal vs. elapsed time How long is a soccer game? Two 45-minute periods 1 hr 45 min – 2 hrs Ideal time: time that something takes when stripped of all peripheral activities Elapsed time: time that passes on a clock/calendar

Ideal time is easier to estimate It’s easier and more accurate to predict ideal time than elapsed time For elapsed time you need to consider external factors Example: in a soccer game’s elapsed time we need to consider penalties, injuries, weather…

Ideal time in the software context Ideal time: time it would take to completely finish a user story if It’s all you worked on You had no interruptions All the resources you needed were available

Why ideal time ≠ elapsed time Vacations Meetings Phone calls Email Training Interviewing Debugging current releases Task switching due to multitasking …

Example Ideally Monday has 8 work hours Monday has: 3 hours of meetings 1 hour of email 4 hours left for the project But instead Therefore, this developer will take two calendar days to complete one ideal day of work

Ideal time as an estimate of size Instead of story points, we can estimate the size of a user story by estimating the ideal time it will take to finish it Velocity will now be in units of _________ Example: How many weeks will it take to create an 80 ideal-day project if a team’s velocity is estimated at 8 ideal days per 2-week iteration? 20 weeks

Ideal time of the group not individuals If two people work on a story for a full day = 2 ideal days To stay simple and to keep the “we’re all in this together” mentality, avoid writing separate estimates for each team member Example: not 4 programmer days + 2 tester days – just say 6 ideal days Not worth the extra effort

Story points vs. Ideal days Now, what’s a better unit for estimating size: story points or ideal days?

In favour of story points… Story points help drive cross-functional behaviour Story point estimates don’t decay Story points are a pure measure of size Estimating in story points is typically faster My ideal days ≠ your ideal days

Story points help drive cross-functional behaviour Story point estimates are based on discussions that result in one number representing all of the work for the whole team In ideal days, members start to think about how long “their part” will take

Story point estimates don’t decay An estimate in ideal days can change based on a team’s experience Example: Developer estimates a small application written in a new language as 5 ideal days Same developer 1 month later estimates an equally small application as 1 ideal day, because she now has experience with the language Problem: 2 applications of the same size with 2 different size estimates

Story points are a pure measure of size Because it’s size, we can estimate story points by analogy only Studies show we are better at relative estimating. We’re better at estimating “this is like that” than we are at the absolute size of things No temptations to compare them to reality and pressure to make actual day = ideal day Boss: “Why did you only complete 8 ideal days of work in a 10-day iteration?”

Estimating in story points is faster When using ideal days, we tend to think about the details and tasks necessary to develop the story Story point discussions are more focussed on high-level discussions

My ideal days ≠ your ideal days One fast runner and one slow runner stand before a 1km race They agree on the size (1km) of the race Fast runner says it will take her 5-min; Slow runner says 8-min ?! Same problem exists in ideal days. Usually resolved by: Programming in pairs Having teams of similar skill Putting the estimate of the person likely to work on it 

In favour of ideal days… Ideal days are easier to explain outside the team Ideal days are easier to estimate at first

Ideal days are easier to explain outside the team Ideal days have an intuitive feel which makes them easy to understand and explain However, explaining story points is a good opportunity for introducing other important agile estimation concepts Concepts such as cone of uncertainty, velocity, …

Ideal days are easier to estimate at first Compared to ideal days, estimating in story points can be difficult and strange at first, especially with no baseline of previously estimated stories to compare with However, this feeling quickly diminishes

Conclusion Based on the advantages of story points, we will insha Allah be using them for the rest of our work in this course

Conclusion: Test your understanding List three reasons why elapsed time does not equal ideal time. It’s easier and more accurate to predict elapsed time than ideal time. T/F? When estimating in ideal time, assume: (1)_______, (2)________, (3)__________ State two advantages in favour of story points.