This week's book giveaway is in the General Computing forum. We're giving away four copies of Arduino in Action and have Martin Evans, Joshua Noble, and Jordan Hochenbaum on-line! See this thread for details.
I have a basic question. In Agile methodology, is it fair to link story point with number of effort hours to different task in that story.
Like 5 point story should be not greater than 20 effort hours and 8 should be 40 hours. I have no idea this is right approach or not. If right, do we have standard number published anywhere ? just to see when different teams are working in project, then how standardization happens?
For this or any other estimation for your organization, you should collect historical data and use that to baseline your new estimation guidelines. You should consider the number and kind (normal/experts) of workforce in your organization who executed past projects.
If there is a fixed relation between story points and hours, there is absolutely no reason to use both IMO.
We have used story points as a measure for complexity/time relative to the other stories in the product backlog, not for an estimate of how long it will take to finish the story.
During the sprint planning, we estimate how long time we will spend on each story, using hours only.
Be pragmatic. Whatever works for one team may not work at all for other teams.
Also, be sure to remove such uncertainties. If the team doesn't understand what a story point means, agree on a common definition or don't use it at all.
Its totally relative.
Story points are not units of time they are units of size.Any relationship with time is again subjective.
I would need to break down tasks in each story point,estimate ideal hours of each task, then aggregate them.
Then you can see in a sprint how many hours are available on an average basis and then you can estimate.
slowly in following sprints you would learn the velocity range of your team and then you can put the story points accordingly in your product backlog.