No story points ..Only Hours.. Will it work ?

What are downsides that you have identified yourself so far? What could management do with this normalized style of estimation?

Hi Vishal,

It would be beneficial to read more on relative and abstract unit measure vs absolute unit measure as in hours. Abstract unit measure helps the team estimate when uncertainty and complexity it is high.

For example - Story A has 3 tasks

Task A - 3 hours

Task B- 2 hours

Task C- 6 hours

Do you think a team should estimate to that level of granularity during Product Backlog refinement?

Noted !

I would stick to relative estimation.

Thanks to Sander, Ian and Lonut.

It's like planning a roadtrip from Amsterdam to Rome. According to Google Maps it would take me 16 hours and 40 minutes. However, I can pretty much garantee you that it's not gonna take me 16 hours and 40 minutes. 

What I can say though, is that it's gonna take me roughly 8 times longer than it would take me to get to Brussels from Amsterdam (keeping the Fibonacci sequence in mind). 

We as humans are really bad at exact at estimation. We're much better at comparing, like user story A is the smallest and user story B takes twice the amount of effort (time/complexity/uncertainty etc) to complete, compared to A.

Very well explained Sander. Got your point.

Appreciate your time.

Hello,

There are for me many reasons why not to estimate in hours. You got the first from the comments of ian and Sander.

The second is : Do all the developpers in a team have the same level, and same knowledge? One can do a task in an hour, while the other might do it in 4. A last point, if you do so, you allow comparisons, (like : He did it in a day, I can do it in halp a day, ...), and this is not good for the good mindset / collaborative atmospher you want to see in a dev. team.

@Zakaria- Thank you for sharing this point of view.

It's like planning a roadtrip from Amsterdam to Rome. According to Google Maps it would take me 16 hours and 40 minutes. However, I can pretty much garantee you that it's not gonna take me 16 hours and 40 minutes. 

What I can say though, is that it's gonna take me roughly 8 times longer than it would take me to get to Brussels from Amsterdam (keeping the Fibonacci sequence in mind). 

And if it's too intense to travel all the way from Amsterdam to Rome without stopping, perhaps you'll want to break that up into smaller journeys. Maybe you'll go to Antwerp, Luxembourg, Strasbourg, Bern, Milan, Florence and then Rome.

Reducing your journeys to the "right size" could be the best reaction, once you've estimated how far you need to go.

And if it's too intense to travel all the way from Amsterdam to Rome without stopping, perhaps you'll want to break that up into smaller journeys. Maybe you'll go to Antwerp, Luxembourg, Strasbourg, Bern, Milan, Florence and then Rome.

Reducing your journeys to the "right size" could be the best reaction, once you've estimated how far you need to go.

Cannot agree more.

One of the reasons you don't try to estimate at high levels is that there are too many unknowns. Estimating in hours is best when you are dealing with things that are fairly well known.  



The second thing that will cause problems with estimating in hours is when you assume that the initial estimation is anything other than an estimate. 



What I've found works best is to keep your tasks to what can be completed in a day or less.  That way you can track them on a day to day basis.  If something doesn't get done that day, then you ask for the person doing the task to reestimate how much time they have left and what is keeping them from being able to complete the task.

The problem with relative estimation is that it is nearly meaningless.  You might just as well just count the numbers of stories you finish in a sprint, you'd get the same results.

The problem with relative estimation is that it is nearly meaningless.  You might just as well just count the numbers of stories you finish in a sprint, you'd get the same results.

I wholeheartedly disagree with your assessment, Larry.   Relative estimation is quite effective as both a lightweight estimation tool and a guide for Development Teams and Product Owners to assess how much work can reasonably be offered/accepted into a sprint.

What do story points tell you that the number of stories completed doesn't?

What do story points tell you that the number of stories completed doesn't?

Story points allow for stories of different sizes. Numbers of stories imply that stories are all the same size. If they are not, it's not a good reflection of the amount of effort.

Story points can also indicate if a feature is complex or has some unknowns to it.

I agree that "tasks" should be small, but "stories" can vary in size.

Story points allow for stories of different sizes. Numbers of stories imply that stories are all the same size. If they are not, it's not a good reflection of the amount of effort.

In principle, both methods embrace imprecision. Just like not all 2 pointers are exactly twice as big as a 1 pointer, we can accept that not all items are the same size.

But there will be an average size, so it is possible to make predictions based on throughput, if there is a consistent way of breaking the items down to the right size.

I have been in teams that have struggled to estimate relatively in story points. In one team where I was a developer, we found that things we estimated at 1 or 2 points were generally manageable, but 3 and 5 point items tended to be much bigger than we had realized, and often took many times longer to complete than the smaller items.

We understood that this was happening, but seemed incapable of correcting it. Instead, the only solution we found was to break up anything that was 3 points or larger.

Simply counting story points can be unempirical. It implies proportionality that is actually based on guesswork. Unless you can be confident that the estimates are actually in proportion, you might have less accuracy than just counting the items.

Furthermore breaking items to a roughly consistent size may bring more stability to the workflow. If the team is using Kanban, it might become apparent that large items cause big queues to emerge behind them, as while the large item is being worked on, several smaller ones might be waiting to be reviewed/tested/deployed/etc.

Simply counting story points can be unempirical. It implies proportionality that is actually based on guesswork. Unless you can be confident that the estimates are actually in proportion, you might have less accuracy than just counting the items.

@Simon, any estimation, whether relative, or through time measurements, or through counting the number of stories, is all "guesswork" in my opinion.   Where empiricism is critical to me in this process is through the Daily Scrum, where the Development Team can inspect and adapt their work based on the challenges they're facing and the progress they're making.

The discussion above is why I advocate using estimates (leading indicators) AND throughput (trailing indicator).  In my opinion neither is enough alone.  Put the two together and it can start to show a picture. For example

Scenario 1

Sprint A backlog is made up of ten 3 point stories.  At the end of the sprint only 8 of them were completed.

Scenario 2

Sprint B backlog is made up of ten 8 point stories.  At the end of the sprint only 8 of them were completed.

That tells me that the team might be having difficulty with their estimations since they were able to complete the same amount of stories in both sprints.  This is particularly telling if that happens across many sprints.  But during that time, any estimation that the PO needs to make about future delivery could be done based on the 8 story completion rate. 

I have 3 teams that I work with currently. Since their formation, I have tracked the number of points taken/completed in each sprint as well as the number of stories taken/completed in each sprint then charted those numbers. The points line has had wild swings over time as they start to work on new features/initiatives that start to smooth out as they become familiar with the problem. But the story count line has stayed relatively flat from the beginning. Empiricism tells me that their estimation is good when working on known problems but difficult when working on new things. However, they are fairly confident in the number of stories that they can get done.  Is that a conscious thing?  It may not be but it is still something that can be proven to be true. 

Estimates are great for having an idea of the inferred complexity before work begins. It can help a team estimate a forecast of a body of work.  But having a second data point such as usual throughput also helps in making the forecast better.  Very seldom does anyone make a decision based on a single point of data for anything in life. 

That is my simple and humble opinion and may not reflect those of other professional Scrummers. Scrumilists? What is a good single word for us?

But having a second data point such as usual throughput also helps in making the forecast better.

>>  Are you suggesting the team performance based on the avg velocity plus the count of stories completed by them each sprint?

@Harshal  That is one way of doing it but as with all things agile, it isn't the only one.  Everyone that has contributed to this discussion has valid points and good reasons for them. As I stated, my opinion is that having multiple data points with which to make a decision is better than making one based on a single. That is common among all of the respondents. No one said "use the <story points/number of stories completed> from your last sprint to determine what to pull into this sprint".  Everyone advocates for having multiple data points to influence your decision. Whether those data points come from a single set of data (i.e. story points or completed stories) or from a combination of data types (i.e. story points and completed stories) it is best to use data sets rather than data points.  You have to identify what works best for your teams and it may not be the same set of data for every team.

My preference is to use two types of data, leading and trailing indicators.  Leading indicators are based on your prediction/estimate/guess of the effort you are setting out to perform.  Trailing indicators are based on the actual work/effort that was undertaken.  Neither is completely right but neither is wrong either. The example I used is just one of the many combinations that I have used. I will admit it is the one I use most and have the best success with helping teams understand but it is not the only one. 

Find what works best for your team. It may entail you have to track a number of items over time in order to identify trends that can be used to help the team. In the interim, while you collect the data, do what you can to help the team with what ever indicator that they choose to focus on. 

Nobody has a fully functional crystal ball that tells the future.

Every estimate is wrong, unless it is a lucky guess that accidentally happens to be correct. 

If you make an estimate look precise, you generate a false sense of certainty and by extent a false sense of security.

Don't fool yourself or your stakeholders by making a precise planning.

Making a 'precise' planning takes a lot of time and effort that could also be used to create valuable software.

That being said, not planning at all is also not helpful. Your stakeholders need some kind of indication when they can expect something, so they can prepare their organisations. So estimate, but don't spend a lot of time and effort on it.

If you estimate a bunch of PBIs, some will turn out smaller and some will turn out larger. In the end, it usually evens out. This is the law of the large numbers.

So estimate roughly and communicate clearly to the stakeholders that these estimates are inprecise.

The verb planning is great, as you think of the future and what you can potentially achieve.

The noun planning (or plan) is not so great. It is yesterday's weather forecast for tomorrow. Baselining your vision of the future and treating it like remains true over time is madness. Today's weather forecast for tomorrow is most likely different from yesterday's.

One of my favourite quotes is from Dwight D. Eisenhower: "In preparing for battle I have always found that plans are useless, but planning is indispensable."