Hello, Chris here again, ILAO's ScrumMaster for the Tech Transformation. We started our 30th Sprint today, and while we’ve come a long way, we’re still making progress towards fully taking ownership of the scrum process. One of the most difficult concepts for us, and one which I think many new scrum teams struggle with, is the idea of story points.
What are story points?
Story points are an estimate of the team’s work capacity for a given sprint. Story points are meant to be flexible, meaning they do not always correlate directly to the hours of work spent on a particular story. Story point values (almost) follow the Fibonacci sequence, which avoids splitting hairs because it forces the team to choose between exponentially increasing point values. There are several card systems and smartphone apps that allow the team to vote on story points together simultaneously - this helps to avoid vote bias by preventing team members from waiting to see what the lead developer chooses.
How can story points be useful to the team?
Story points help the team predict how much work they can accomplish during a given sprint. By measuring how many story points they have completed in past sprints and developing consistency in point assignments, the team can get a pretty good idea how much they will be able to achieve during the next sprint. For example, our team tends to average between 1 and 2 story points per hour of work. Other teams may weigh points more heavily, but consistency is the key. It is helpful if the Scrum Master prepares reports for the Sprint Retrospective Meeting detailing the story point breakdown from the previous sprint. Each team member should know how many points they completed to better estimate their capacity going forward.
Should Story Points change mid-sprint?
Inaccurate story point estimations can be common among new scrum teams. We have struggled with whether we should reevaluate story points mid-sprint if it becomes clear that we didn’t accurately estimate a story. The current consensus is that if we’re way off, we should re-estimate the story during the next Daily Scrum Meeting. Our team has also found it helpful to reevaluate their commitments mid-sprint, so that we can adjust the sprint scope if necessary. This may not jive with the “traditional” scrum rules, but our team has found it helpful, and after all, the process should serve the team, not the other way around.
30 sprints down, only a few more months to go!