Agile methodology is a popular method in modern software development industry, but some of its definitions and practical usages are still ambiguous.

I will provide some questions I encouter and its answer below to clarify the most debatable term: Story Point.

Q: Should I map story point to man-hours?

Scrum Guide didn’t mention anything about must-use Story Point, but estimation. And purpose of this estimation is the consensus on Scrum team’s effort at Sprint completeness. This means any estimated methods could be used but adherence to the exertion of the team.

For example: a simple login task should take 1 hour to implement but have to take up to 24 hours for database team building up databases, so the total is 25 hours.

This is wrong because it is only 1-hour effort. Problems here are the priority of the task. It should be low priority or put on hold until the database team’s task finished.

In case the login task must be finished with highest priority, you have to split it into 2 tasks: 1 is implement the task with small effort and 1 for collaborating with database team with bigger effort.

Therefore, the answer is “No”.

Q: We are an outsourcing company and man-hours is an essential factor for bidding cost estimating, what can we do without it?

Agile is a method helps us get a potential deliverable product at the end of each sprint based on sprint estimation. Using Agile to wrap the whole project into 1 estimation is not feasible unless you got in hand all details and clear requirements. But it is Waterfall not Agile.

If you still persist to use Agile, my advice is adding some buffer or risk estimation. Eventually, it is a part of business, right? 😊

Q: With 1 estimation, a senior could complete in 2 hour but a junior could take up to 8, how could we eliminate this difference?

This difference is unavoidable, but if it became noticeable, then problem is on the Backlog refinement, because the result of refinement is a relatively agreement effort number.

If senior developers can finished their tasks in a short time and rest till the end of the sprint, that is none of our business because it is their abilities, personal skills, and knowledge.

In the end, we assess Scrum team achievement, not an individual workload.