HOW TO ESTIMATE OVERALL EFFORT FOR THE WHOLE PROJECT BASED ON PRODUCT BACKLOG ESTIMATION?

"Dear all,

We are just starting the Scrum in a project team. We just finished the product backlog estimation. We used "Story Point" to do the estimation for Product Backlog Items (PBIs). Then I got one questions from the Scrum Master: We are using "point" as the unit of PBI, how do we estimate the effort based on the "story point" for the whole project?

I suggested to make a rough calculation, for example: 10 points is equal to 1 man week's effort. This will be a very rough effort estimation (maybe the deviation will even more than 20%), the team will adjust it based on the result of several Sprints.

This the first time the team using Scrum. I don't know if this is a good answer? Are there any better suggestions?"

"... One note of caution: User Story Points are subjective. What one developer says is 3 another may say is 5 man days. We are actually coming to the point of estimating based on ideal man days and earned value management. Recognize in your estimates the overhead not associated with actual development time, like meetings, etc. Developers cannot work for 8 hrs a day on writing code, they have to participate in sprint planning, reviews, daily standups, etc. ....

Its definitely tricky..."

PIERRE’S ANSWER

Translate estimation points into men work is noisy for your Scrum. Let me explain: if you're handlinh that way you will see that your team is "loosing" too much time in non-productive stuffs like meeting, estimation, etc...

The translation in men work make just sense for the reporting: here the Product Owner can use the velocity to give a men work feedback.

But, remember, defining this kind of metrics has just sense if you are managing your project in a predictive way (a bit like a oracle...).

In Scrum:
- if my Vision is clear
- if I have a Roadmap to start
- if I have a realistic Product Backlog
I need 3 Sprints to get an average Velocity to plan my Release.

In this way, I cannot consider an men day evaluation but put enough PBL items into the Sprint and Check out Release plan.

In Scrum the mindset is reverse to the traditional PM:
- I know how much people I got
- they spend 40h/week
- I know how much they're paid

If you have a PO, he should know that Metrics in Scrum are very simple: Velocity, Backlog Size, Burndown and Time to Market.

N.B. Earned Value estimation is not Team's job but Customer's

Posted via email from pierreneis's posterous