Having recently been asked the following question on whether story points should instead be referred to as man-days, I wanted to share my top 3 reasons as to why estimating should not be approached in this way.
“At my work place, story points are referred to as the number of man-days. Is this the correct way!? I say to them that it’s the level of difficulty you give points to, not the man-days. But at the end of the day, they want to know how many days the work would take. Please can you help me with some tips on how to explain this.”
Story points should NOT be explicitly linked to man-days of effort, as they are meant to be a purely relative estimate i.e. the team believes that a Story estimated as 8 points will be about four times as much work as a Story estimated as 2 points.
The advantages of this approach, over estimating directly in man-days, are explained further in my points below – as well as how to provide an estimate of man-days (if we have to) by extrapolating from Story Points.
Relative Story Point estimates are quicker and easier to do. Estimating directly in man-days often leads us to get into too much detailed thinking, even down to the individual task and sub-task level which will take too long and is simply not appropriate at the Story level during Product Backlog Refinement which is when Stories should be estimated.
Task-level estimates (typically in hours) should only ever be made once the sprint has started (Sprint Planning at the earliest) and should be considered optional in any case. Product Backlog Items need to be estimated so that the Product Owner can make decisions around the likely Return on Investment of each item as part of ordering the Product Backlog.
Task level estimates should only be made if it helps the team be more effective in delivering the Sprint Goal.
The team often cannot agree on them because they depend upon the speed with which people will do the work … and most agile teams have both more senior and more junior members. Ask an experienced senior engineer for their estimate in days and they may say 3 days. Ask a junior and they may say 10 days. Who is right? Who is wrong? Well they are both probably equally wrong, but they can’t agree.
If they use relative Story Points, however they will be more likely be able to agree that Story A is likely to be X times as much work as Story B.
If the team changes the way that they are working (for example, perhaps they are going to start automating their testing) then if they have estimated in man-days, they will have to re-estimate every item on their Product Backlog!
If they have used Story Points however, they won’t have to do this as it will still probably be the case that relatively speaking Story A is likely to be X times as much work compared to Story B even though we are changing the way we work. This is important, especially given that an agile team should be continuously inspecting and adapting the way it works and its Definition of Done.
Of course, Story Point estimates can be very loosely translated into man-day estimates through the concept of Velocity, but there are these distinct advantages to using relative Story Points for estimating by comparison rather than directly equating points to man-days or estimating in man-days themselves.
If you’d like to learn more about how to effectively estimate story points, then we have a number of courses available to cover this area in more detail. Simply use the respective links below to find out more.