Here is an interesting discussion between a Scrum Master, who is new in the role and the Agile Coach, sharing it as a blog to reach a wider audience and elicit different perspectives. The options shared are contextual and subjective and I know for sure there will be alternate options, it will be great if you can share your views on the same.
Should we story point Spikes?
The velocity of the sprint in story points, is a rough indication of the value that it provides for the customer. If one thinks along these lines, one should not put story points for a spike.
One of the common scenarios when a spike is created is when the team is not able to size the story, as some investigation / exploration is needed. Spike requires setting aside some capacity to complete that, so that the story can be sized. That size which we provide, after the spike will indicate the value that the story provides.
Spike will need some of the team’s capacity ear-marked for it, so the velocity may take a small dip. Yes, it will be so, just as in the case of a team member being on a training or on leave. The velocity fluctuates…please see the end of the blog to see how the transparency can be brought in.
Should we story point defects, which come in ad-hoc? We are setting aside a % of the team’s capacity for it
No we should not be sizing them. The defects typically do not add new functionality/value; their removal is making things work as it was intended to be. We are planning the sprint with the adjusted team capacity, after setting aside some for the ad-hoc issues.
What if those issues result in enhancements, we are adding value right? We may also like to know how much of ad-hoc work gets done. If so, we could size the ad-hoc issues as and when they come. But when we plan, we need to use the velocity, excluding the story points for the ad-hoc issues. This is because the team is setting aside some capacity for defects.
Do look at the end of the blog for additional info on transparency.
When do we size the stories? Isn’t it only during the backlog refinement?
Yes, typically stories get sized in the backlog refinement meeting.
But story may be added to the backlog after that, though rarely, such stories could be sized in the sprint planning meet.
If the team as an exception, accepts a story in the middle of the sprint, they should size it at that point, if not already sized.
The goal is to have a consistent view of the velocity, so size all stories in the planned or the updated sprint backlog.
Getting a transparent/sensible view of the velocity – sprint start mail
This is a simple practice that has evolved, as I worked with various teams that were adopting Scrum. The team compares the planned velocity in the current sprint, with the velocity of the past sprints. They find variations and are perturbed and like to have it figured out.
Let’s look at a few scenarios:
Here is a scenario – The planned velocity of the current sprint is 60 story points, the planned velocity in the previous sprints was around 50. there appears to be a difference of 10 story points. Let’s assume that the capacity of the team is consistent across the sprints.
When the team looked into the details, they noticed that of the 60 story points, 10 story points are due to the couple 5 story point stories not completed/done in the previous sprint. It adds 10 story points, but a lot of work on these stories is already in progress. Considering this, we can say that the ‘real’ planned velocity is somewhere between 50 and 60, closer to 50, so the team is forecasting to do more, in this sprint than in the previous ones.
Let’s look at another scenario – the current planned velocity is 55 story points, whereas the velocity in the previous sprints is 60, there appears to be a difference of 5 story points.
When the team looked into the details, they saw that in the two-week sprint there is a holiday. They have 9 working days instead on 10. Roughly, 10% less capacity than the normal, so 60 – 10% that is 54 story points, so the velocity of 55 is fair.
Note that there could be reduction in capacity due to team member being on leave, training etc.
We found that a sprint start mail demystifies the velocity and keeps the team grounded. Here is an example (text in the parenthesis added as explanation):
Team plans to do 9 stories which size up to 65 story points this sprint, of this we have 8 story points from couple stories not done in the previous sprint. (‘Real’ velocity is between 57 and 65, closer to 57)
The team capacity is at 80% of the normal due to a holiday and few planned leaves and training. (“Real’ velocity is between 71 and 81, closer to 71. Dividing the above numbers by 0.80)
In the last sprint we planned to do 11 stories totaling to 70 story points and did 9 stories adding up to 62 story points. (Provide context to previous sprint info).
This practice leads to better swarming in the team, partially contributed by the transparency in the velocity and the factors that influence it. This also helps the team focus on the sprint goals over individual stories and tasks.
The mail can call out any Spikes being done in the sprint too and add info that may be wordy to include in the Sprint Goal.
My experience has been that the teams are very particular about this, at the start of their Agile Scrum journey. Often this practice gets dropped, as they progress on their journey, from doing agile to Being Agile.
