Hello readers, apologies for the lack of posts lately; lots of work at hand. Today’s Ask an Agile Coach question comes from a comment on the last installment, which is rephrased here. In one form or another, I have gotten this question for years now:
Should I count partially complete user stories in my velocity? For example, if I have a 100-point story that’s almost done, should I add 80 points to my delivered points total for this sprint?
The answer is no, you should not.
Remember that Scrum was designed to enable empirical process control for software development. The team is committing to work in fixed intervals, with the intent being that a team becomes quite proficient at knowing how much work they can move from concept to customer within that fixed interval. To that end, the points that go into velocity are points delivered. Delivered points come from stories that are completed. When stories are incomplete, they are carried over, and velocity is lower than expected for the Sprint. Hopefully, these points plus the additional work pulled in will cause the next Sprint to have a higher number of delivered points and the two values will level one another out.
If a team or Scrum Master insists on counting part of a story’s points in velocity, they are masking a symptom and thus choosing to ignore the underlying causes. This short-circuits the process and the valuable feedback it provides.
If a team finds itself with carryover continually affecting velocity in a negative manner, it is usually an indication that the team needs to improve their ability to plan and commit to work within a Sprint.
One area to target is honing the ability to break work down into thinner vertical slices of user-oriented functionality. If stories are perpetually 50-80% done at the end of a Sprint, revisit the team’s approach to user story writing and trying to carve smaller functional slices (but not so small that you violate the INVEST heuristic from Bill Wake; an alarming number of practitioners have fallen into hyper-granularity in their stories).
Another area to address is the cross-functional team’s (and your Scrum team is cross-functional, right?) understanding of what it takes to go from concept to customer. If stories seem to invariably look smaller or the team seems to perpetually overcommit, it may be that some of the more vocal team members are expressing estimates that reflect a myopic focus on simply the writing of code instead of all the tasks involved in completing a given story. Encourage the other cross-functional members to speak up in User Story writing, Sprint Planning, and Backlog Grooming about what they need to do to complete the stories in question. This has always resulted in more accurate story sizes for me over the years.
Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.