User stories in Scrum are work items that the team implements and turns into working software. The product owner is mainly responsible for developing user stories. However the team will have to work with the product owner to refine the user stories to ready user stories. This means the stories must be clear, concise, and immediately actionable. I’ve personally seen many teams struggling through the sprint, holding endless debates and get nothing done by the end of the sprint. The reason was simple that the user stories were not actionable and the result was frustration amongst team member as well as product owners.

Understanding Agile Story Points or Scrum Story Points seem quiet challenging if you are only experienced with time based estimations. This post hopefully eases the situation and makes Story Points clearer.

Story Points are commonly used in Agile software development. When talking about Agile software development we are talking about Scrum in most cases, but there are other methods as well.

Historically Story Points arise from a military context, when during the Cold War the Delphi Method was developed to forecast the impact of technology on warfare. The goal was to get a forecast or estimation of probability and expected development time of a certain technology in a single indicator.