Going from Story Points to Man Days

Last post 10:01 pm January 13, 2022
by Mario De Caerlé
4 replies
Author
Messages
09:22 am January 13, 2022

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?

06:29 pm January 13, 2022

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. 

 

06:51 pm January 13, 2022

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.

10:01 pm January 13, 2022

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.  

https://actionableagile.com/resources/

10:01 pm January 13, 2022

Have you looked at Kanban's Service Level Expectation (SLE) and especially how you can get it calculated?