Estimation and days

Question

How practical is using days estimations for stories in a sprint instead of another approach (e.g. story points)?
It seems to me that using days, links stories to specific developers only while ideally a story should/could be picked up by anyone in the team.
I am interested in possible cases that this works out well and the overall approach

Answer 1

Using ideal time - days or hours - is both practical and viable.

Although my personal preference is to not assign estimates in time, points, or size to work and to focus on making each unit of work the smallest useful, demonstrable slice that can be used to elicit feedback and counting the units of work per unit of time for planning, estimating in ideal time is the next best option.

When using time, it's important to use ideal time. Ideal time is how long it would take to complete the task with the assumption that there will be no interruptions or no unplanned problems.

Based on historical data, you can determine a relationship between ideal time and elapsed time. In Estimating Software Costs, Capers Jones uses ideal time as being about 83% of elapsed time - that is, one work month would be 132 hours or one work week would be about 33 hours. I find this a bit aggressive, so I tend to use closer 70%, making one work week about 28-30 hours. You can calibrate the relationship using data from your organization and how much time people dedicate to the effort.

It's also important to consider the average person on the team. If the most experienced person for the task estimates it at 4 ideal hours and the least experienced person estimates 16 hours, you shouldn't use either of those. Depending on the number of estimators, you can consider using the median, truncated mean, or geometric mean.

Not only do you need to consider the individual, but the estimate should consider the team's processes. A team that regularly pairs needs to account for this when considering how much time to plan on, both in the total (you may not simply be able to add up the ideal hours per person) and on each task (pairing may take longer to compete a task).

All of this sounds like a lot, but the end result is something that is pretty easy to understand and communicate among various stakeholders. The idea of time, ideal time, and how this fits into scheduling and forecasting isn't terribly difficult once you get a little bit time experimenting.

Answer 2

How practical is using days estimations for stories in a sprint instead of another approach

In my practical experience, it's entirely impractical and counter productive.

It doesn't really matter whether it works well or not, the name "day" is already taken.

And for higher ups, it's ambigous. If you write "it takes 5 something something days" it doesn't matter whether you wrote "5 ideal days" or "5 man days" or "5 days on average". What is stuck in the head of normal people and bosses alike is "5 days". All that "but I did not mean real days" is irrelevant, because that is in your head. If you bring that up after you failed the deadline of 5 days that your bosses understood (even if wrong), it will sound like a whiny technical excuse for you failing your project.

A really nice side effect of Story Points is that you cannot just skim the mail, break a half sentence out of context and come out with a totally faulty understanding of how long it will take. You could argue that doing that is a mistake anyway... but telling your boss they constantly make mistakes is not good for your future on that project.

So in an ivory tower, on paper, in an exam scenario, "ideal days" might have merit. It might work great. In the real world, in my experience it's just a communication disaster waiting to happen. And make no mistake, if you and your boss "miscommunicate" (aka they didn't spent enough time to properly read and understand their mails), that's on you. You get paid for making sure that doesn't happen.

Answer 3

Relative estimation works because people are generally better at relative estimates than absolute ones; relative estimates are easier to manage (because they seldom need to be re-estimated) and velocity is evidence-based rather than purely based on forecasts and guesswork.

It is possible to use "ideal days" as the unit of relative estimation - but only if the people receiving the estimates accept that less than one ideal day's work gets done in a day. Some people tend to have trouble with that concept however, leading to awkward questions like "Why are the team only working 8 days out of 10!?" The advantage of using abstract points rather than days or hours is that it sidesteps any assumptions about what is the "right" estimate or velocity.