Going from Story Points to Man Days
We work on a team that it follows many of the Agile Scrum principles. We estimate User Stories with Story Points, using Poker Planning, which is resulting fairly good, promoting discussion and improving these estimations over time.
However, sometimes, for budget reasons at a higher level, we are asked to provide estimates in man days for a number of requirements (User Stories).
Currently, what we do is gather, look at the User Stories and their Story Points, and under an assumption that 8 points is a developer capacity for sprint (ie, 10 man days), we do this conversion, and provide that information under the premises "based on what we know at the moment, this work is estimated on X M/Ds)".
I don't have a clue if this a (bad) common practice in organizations where this kind of information is asked, or if there is any other better alternatives?
sometimes, for budget reasons at a higher level, we are asked to provide estimates in man days for a number of requirements (User Stories).
Why not divide the estimated size of the Product Backlog, in points, by the estimated velocity?
It's the Sprints they're paying for, and the work that will be Done in those Sprints will be emergent. Scope may flex, and value thereby optimized by the Product Owner, over however many Sprints are funded.
If you need to estimate in time, why not just estimate in time to begin with? You don't need to be using story points and planning poker to be using Scrum - none of these are mandatory elements of the Scrum framework. Why don't you just estimate in ideal hours? There are some common, accepted conversions from ideal hours to actual hours if you don't have historical data for your organization and team.
We estimate User Stories with Story Points, using Poker Planning,
I have never seen anything in the Scrum Guide that states this as a Principle. In fact, the word "estimate" is not used in the Scrum Guide. But that doesn't help answer your question.
I have found that estimating is difficult for people. And to make it worse, if a developer says "I estimate that will take me 4 hours" people will hear "If I start on that at 9:00 am, it will be done by 1:00 pm". But we all know that is very seldom the case.
If an organization wants to use information for budgeting purposes I have found that using metrics like Cycle Time or Lead Time work better. Using the mean or average of those values you can then predict how long it might take to complete a body of work. Those values are usually more accurate than an estimate made without knowing all of the information.
I suggest reading these books by Daniel S. Vacanti to get better info on this process.
Have you looked at Kanban's Service Level Expectation (SLE) and especially how you can get it calculated?
"If you need to estimate in time, why not just estimate in time to begin with? "
Because man days, man hours is an abstract. Your lead dev will do this in 3 hours, if you dump 5 undergraduates fresh from college it can take them one week to do this.
So you estimate it in abstract, multiply it by velocity and then you have work estimate in sprints. Because you do deliver in sprints so there is no smaller amount of time. You can convert sprints into team-weeks, but not into man-weeks. Because your lead dev without testers and other team members won't achieve this velocity. Team is one, individual guys are other thing. Arithmetic of translation between team time to single man time doesn't work.
Your lead dev will do this in 3 hours, if you dump 5 undergraduates fresh from college it can take them one week to do this.
This is a common mistake in estimation, but it is one that is easily avoidable.
When estimating using any method, whether that's time or relative estimation, you need to consider the team as a whole. When estimating, you often don't know who will be doing the work. If you consider the most knowledgeable and qualified person doing the work, you'll often underestimate. If you consider the least knowledgeable and qualified person doing the work, you'll tend toward overestimating, especially since that person may gain knowledge and experience before starting. There are techniques to consider the arithmetic mean, geometric mean, or disregarding the highest and lowest estimates entirely.
The team also has to consider their way of working. A single highly experienced person may be able to do the work in a few hours. However, if the team practices pairing, that highly experienced person may pair with a less experienced person and teach them along the way, increasing the amount of time it takes to complete the work. However, that experience could very well be worth the additional time to finish the work.
It still comes back to estimating in time is a better option than relative estimates, at least at a refined unit-of-work level. Although I would still suggest that the team skip estimates entirely, focusing on the smallest valuable unit of work and tracking flow metrics like cycle time and throughput to tell how long it takes the team to complete the average piece of work with some level of confidence.
No matter how much we avoid metrics, it is essential part for leadership and stakeholders to showcase org data for progress. While the ways to estimate is different for all levels, the actual data used is from the actual team working on the change. This is the team who is building functionalities in sprints.
Now there are 2 types of estimations: - 1) Relative & 2) Absolute.
Relative is when the team is new (either with experience or for the product) and have worked for very little time. In that case, they compare similar items from the backlog and try to size them. Most trusted method used for this is t-shirt sizing.
Absolute is when team is matured enough (technically and on the product) so that they can estimate right down to the day(s) in which the work can be done. Most trusted in this is Story points.
Now the main aspect of converting Story points to Man days. For betterment of managing, I usually go with 1 user story point = 1 working day. Now, the number of hours in which each individual works may differ, amount of quality the resource generates in that time differs. So on an average, everyone is OK with estimating in how many days the work can be done.
Lastly, I do not encourage to go beyond 3 user story points (which accounts to 3 working days). In that case, we need to break the work further as I do not prefer lingering around on 1 item for more that 3 days. Hope it helps :)