User stories and story points
A user story is a description of functionality at the lowest level of granularity that can be independently developed and demonstrated to generate feedback. Since, in Scrum, we focus on developing the smallest incremental functionality of the product, we use the user story as a unit of development. We also need to assess the size of the software being developed per sprint. The size of the user story in terms of story points is decided mainly by:
- Complexity (related to development)
- Doubt (clarity on what is really needed)
- Effort (work needing to be done)
This approach is logical and similar to one taken for use case points or function points. (The only difference is that while use case or function points are "counted" as an absolute measure, the story points are "estimated" as a relative measure.)
Hence it's a good idea to assign story points to these stories and to track the velocity of the team by means of these points. Keeping the velocity at a sustainable constant value is the responsibility of the team.
User stories and business value
Every user story, when developed, must add to the business value as endorsed by the product owner. One user story may add much more business value than another. The business value of the user story decides its place in the prioritized product backlog.
Assessing the business value of the story, prioritizing the story accordingly, and passing on this understanding of value to the team is the responsibility of the product owner.
Do the story points indicate business value?
The answer is no. As stated earlier, story points constitute a sizing technique to indicate how big a story is. A bigger user story may have less business value than a smaller one, and vice versa. Well, then, if we measure velocity, does it indicate the business value delivery of the team? Again, no.
In short, velocity and story points developed can indicate only the pace and productivity of the team.
A team with constant velocity may give varying business value to the product owner. The only way of ensuring incremental business value along with the productivity is to prioritize the stories effectively and give the best possible understanding of this story prioritization to the team. That's why product backlog grooming helps to add business value.
A defect is an understanding of deviation from the expectation. The severity and effect of a defect will vary from "ignorable" to "show-stopper." During the sprint, there can be defects of varying severities, and the team must make decisions to "fix in this sprint" or "push to the product backlog." This is typically decided based on whether the developed user story still delivers the business value. If a defect prohibiting the execution of functionality, thereby rendering zero business value, is not fixed by the team by the end of sprint, the product owner would not want to consider the story points as "delivered." The story would not be "done." This is quite fair. However . . .
Defects and story points
Many a times, even when the story is functional, the defects are considered "sins committed by the developers," and the product owner doesn't count the fixes or work-arounds as "work done." By not counting this as work, we are not accepting the truth that it eats up the sprint work time, and the actual feature development will be affected. You may not consider it "business value work," but you need to count it for an accurate measure of velocity. If the work to be done by the team also includes defect fixes, we need to size that, and the convenient way to do so is to assign story points to that work. So you can assign story points to the defects and add them to the "feature development" story points. This gives a clear idea of the team's productivity.
Keeping the track of the defect story points separately can help you find out in a quantitative manner how much more feature development the team could achieve in the absence of those defects. This motivates the team, PO, and management to think about defect prevention measures.
Other work items that can be assigned story points
When you have component teams (such as a UI development team or a framework component development team), they don't produce any business value as is provided by "feature teams." In such cases, it's useful to have the components under development at par with user stories and size them using story points. Further, such a work item as "architectural refinement" may be taken up even by the feature teams, and it needs to be counted in size although its completion may not demonstrate business value.
- Accept that defects are "backlog" items. Effort will have to be added for dealing with them in the sprint.
- To understand the velocity, size the defects using story points.
- Separate "delivery of business value" from "velocity of the team." While the former is driven by the PO, the latter is driven by the team.