User Story story pointing
User Story story pointing is hard to apply.... development team consists of developers, testers. While development team story pointing the user story, how the story pointing should be applied in practice.... should the developer story point from developer point of view, testers story point from testing point of view or as whole team should story point to-geother because story point size can vary from developer and testers ?
What is baseline for 1 story - 8 hours as per agile process or guideline ? If the user story pointed as 3 , so if the 2 resources pairing (1 developer, 1 tester) working on the user story should be completed and demoed in 3 days ?
Thank you for clarifications.
User Story story pointing is hard to apply.... development team consists of developers, testers. While development team story pointing the user story, how the story pointing should be applied in practice.... should the developer story point from developer point of view, testers story point from testing point of view or as whole team should story point to-geother because story point size can vary from developer and testers ?
A very similar question recently came up on the forum, and the answers there might help you.
What is baseline for 1 story - 8 hours as per agile process or guideline ? If the user story pointed as 3 , so if the 2 resources pairing (1 developer, 1 tester) working on the user story should be completed and demoed in 3 days ?
If you are going to map story points to hours, what benefit do story points bring? Wouldn't it then just be more transparent to keep your estimates in hours?
Story points are an optional practice in Scrum. What are you trying to achieve by using this particular estimation technique?
or as whole team should story point to-geother because story point size can vary from developer and testers ?
Yes. Estimates (which is what Story Points are) is a way for the team to show that there is a common understanding of the problem being discussed. If all of the disciplines are not represented then there is no common understanding. I suggest that if you are trying to tie Story Points to hours it would be better to just use hours. But remember that you are estimating hours based on known parameters. When work begins, new information is obtained constantly. So the 3 hour estimate might take 9 hours and there is nothing wrong with that. Also, if you are trying to estimate to hours of work, I would avoid planning the Sprint so that there is enough work to keep people busy for 8 hours a day for each day of the Sprint. The reason being that the 3 hour estimate could end up taking 9 hours. Take enough into the Sprint to create a valuable increment of work. Value delivered is the measurement of successful teams, not how many hours you work.
whole team should story point to-geother because story point size can vary from developer and testers ?
That might be a reason...but don’t the team want to estimate together so they can improve their shared understanding of the work involved?