Scrum Story Points and Velocity
How to make a story point estimate for an Agile Scrum user story, and how to measure Scrum Velocity
Story points is a measurement unit used to determine the complexity of user stories in the product backlog. Complexity means how big or small the job is, in terms of effort, resources, budget, dependencies and etc.
Story points are not a time estimate, they help the Scrum team measure the Velocity to achieve the business values. There are different types of scales used to create an estimate of user story point, among them:
- Linear scale (1,2,3,4,5,6,7…)
- Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13 …)
I have chosen to use Fibonacci sequence because it is discrete and distance becomes wider when complexity is increased, this gives better estimation during Development Team voting. You are highly recommended to follow the below steps in order to make a proper estimate of a story point:
- During the Sprint Planning, the Scrum team should find a user story that is clear for all team members and that can be given accurate story points by most. Hence the simplest story can be picked from the backlog. This story will be referenced later as a baseline story where the Development team may refer to, in order to understand the complexity.
- The Development team only votes for story points, they have to hide their votes and raise them at the same time, they may try Scrum Time app on their mobiles. Or just vote on a blank paper…
- If two members of the development team voted with big distance, like one voted 21 story points on a certain story and the other voted 3 story points, then both should communicate and explain their points of view. At the end of the voting, normally the most voted story point is selected, and in general if Development team reached a clear agreement, that is fine if not, they should get help from Scrum Master and or Product Owner. Please note that the member(s) of the Development team who are going to be responsible for a story vote normally like other development team members and they don’t dominate the voting themselves.
- We use private voting and we only show the numbers when voting is finished and at the same time, we do this in order to comply with Conformity, the influence of Majority and or Seniority pressuring to make a decision.
Let us make a small example:
Twitter Profanity — Sentiment Analysis Product Backlog Stories
The Product aims to produce a model that predicts if a tweet contains Abusive or hate speech. The result should be True for Abusive/hate tweets and False for normal tweets; the Product Owner came with the below stories:
- Training Data Acquisition (10K Tweets)
- Training Data Judgements
- Training Data Engineering
- Prediction Models Training/Evaluation/Selection
- QA and Scaling up — Production
The Scrum team met for Sprint Planning and started to measure complexity by giving story points to user stories in the Product Backlog:
For each story, the Development Team starts discussing the complexity by estimating the number of subtasks, dependencies, effort, blockers etc. For instance as we can see after the voting for each story the Training Data Acquisition story was given two story points as one of the Development Team members has a tool that crawls tweets automatically. He verbally informed the team that this tool will reduce the complexity and that it was tested, so the Development team members’ final vote was 2 story points. The Training Data Judgement story requires three different members of the team to review each tweet, then label the tweet with True OR False which would require an excessive amount of effort, so the vote was to give 5 story points complexity.
The team then created a Sprint and decided a time span for the Sprint, Maximum 4 weeks (20 working days).
After a certain maturity, such as after three Sprints has passed, the Scrum team will be able to measure the teams velocity. So for instance, the team has completed 24 story points in the first 3 weeks Sprint, then 22 story points in the second 3 weeks Sprint and 23 story points in the third 3 weeks Sprint, the Velocity should be the average of the three Sprints story points; (24+22+23) / 3 = 23 story points.
Now we know that our velocity is 23 story points per sprint, this will help us estimate how many Sprints the Product backlog requires to finish if we know the story points for all user stories in the Product Backlog.
