Story Points in Agile Software Development
Over the years, I developed a series of training documents and videos for my teams that discuss Story Point estimation. They discuss how they are used and why they are essential. Since I did a previous post about Velocity, it is crucial to lay the groundwork for Story Points so that teams can estimate adequately.
What are Story Points?
Story points are a way to measure the relative effort around an issue. We are not measuring difficulty or the time it takes to do something for one person, but rather the effort needed to implement the work from the team’s perspective.
Example:
An issue may require little programming effort but a lot of regression from quality assurance. This is why Story Points should be decided from a team perspective, not just one person (or division). The developers expected to do the work should make the assessment (whenever possible).
Note: When we discuss developers in this sense, we aren’t just talking about programmers. We can include anyone from programming, testing, or operations, as needed.
Story points display the relative effort, sometimes called Size, of an issue (e.g., Work Items, Tasks, or User Stories). Typically, this is done with a modified version of the Fibonacci Sequence (1, 2, 3, 5, 8, 13, 20). They can also be expressed in other ways, such as colors or t-shirt sizes (e.g., XS, S, M, L, XL, XXL).
Story Points are used because they are an easier way to communicate effort to the business or client. Giving a Level of Effort (LOE) assessment can be binding for a group, as issues pop up from time to time.
It is important to remember that scope and impact are not always the same. The scope of a ticket is specific to where the work is directed. The impact, though, revolves around what is affected by the code. This is where Regression testing is brought in.
Project Managers can use a group's velocity (the average number of points completed during a specific time frame—often referred to as a Sprint) to determine how long it will take for the group to complete the planned features.
An important thing to note is that time is not the only definition of a story point. I have seen many teams use time as the only determination to assign a value to the estimate. If you want that, then estimate the hours instead. Story points don’t work that way, though. You want to estimate the relative effort here.
Why is this important? Different developers will take different amounts of time based on their experience and skill sets. Some developers are better at specific tasks than others. Some have limited experience in the task but want to gain experience. It is up to the team to determine what the task’s relative effort entails, rather than what a specific individual thinks it is. The team doesn’t necessarily know who will perform the task, since estimation is done before implementation. In a perfect world, team estimates are done weeks in advance, so no one knows who will have the capacity to perform the task once it is ready for implementation.
Example:
The team has received a new User Story. The Acceptance Criteria are:
Write your initials on a Post-It note.
Pin the note to the board
The team looks at the story and decides it is an Extra-Small story (using t-shirt sizing or XS). Since they previously assigned a number value to t-shirt sizes, a story point of 1 is automatically assigned.
Now, we hand it off to one person. They hastily scribble their initials on the note and pin it to the board. When everyone looks at the note, they may say it isn’t legible, which requires the person to redo the task.
Suppose we hand it off to another person who takes the time to write their initials carefully, though. Once they have posted it, everyone agrees that the acceptance criteria are met and the user story is completed.
While this example seems simple, it displays where relative estimation goes beyond time. The first person is quick but sloppy. They risk redoing the assigned task, which means multiple rounds of quality checking.
The second person took their time, and only one round of quality checking was required.
But we are talking about a small task that probably balances out. Imagine a more significant task. Something that might take days to implement.
Imagine the same scenario for a Story the team says is larger, perhaps a 5- or 8-point ticket.
Let’s continue with the original scenario, using that point value instead. The first person may cause the ticket to run over due to defect creation. The ticket may fall into another sprint, perhaps introducing new problems. The second person might have shaved off time due to their careful practices and expertise, thus limiting the quality check.
Does this change the story point estimate? Should it?
An important point to make here is that story point estimates should not change during or after the story's implementation. Why? To put it bluntly, the team won’t learn how to properly estimate tickets if the project manager keeps letting them change them after the fact.
Rather than changing the value, bring it up in a retrospective setting.
Here you can ask questions like:
Was the story correctly estimated?
What would have been a better point estimation?
How can we estimate these sorts of stories better in the future?
Over time, the team will improve its estimations, improving the accuracy of the velocity. This, in turn, will allow project managers to communicate a better idea of how long it will take for a team to implement the stories, features, and epics in the future.
Wait…we just found the Time part that project managers need. Isn’t that clever?
