We start a story in sprint 7, but we finish the story in sprint 8. Should we count those story points against 7, or against 8?

Barking up the wrong tree

We are asking the wrong question.

It does not matter whether we add those story points to sprint 7, or 8. That line of thought tells us nothing useful about how we are performing the primary task at hand – deliver correct, well built software in a timely manner.

Make no mistake, when a user story slips into a second sprint, you have a problem with how the work is going. That problem, whatever it is, demands examination and remedy. However, deciding which sprint to stick the story points in neither helps the examination of what went wrong, nor does it contribute to correcting the failure.

Big story

The user story may have been too big. Perhaps we bit off more than we could chew. We should have broken the user story into smaller ones. Watch out for that next time.

How do you split a story into smaller ones? That is a separate question. There are a lot of references on that, which I’ll leave you to research.

We are not efficient

Say we decide that we cannot break the story into smaller pieces. Perhaps something is not quite right with our productivity.

In my current place of work, we get issues that can be finished (analyzed, fixed, tested) in a couple of days by a developer that knows the domain, and the system. However we also have folks that take a couple of weeks to finish the same story. Their work often span sprints. These folks have to come up to speed. There is your problem. Address it.

Perhaps the developer finishes his part, but the issue languishes with the testers because they are swamped with other things. This exposes problems with how we have organized our teams. Protect team members from being dragged into work that is extraneous to the current sprint.

We should have known early

We should have known that a story would not finish, well before the end of the sprint, and we should have taken remedial action right then.

If we know our team, and our engineering environment, we should have been aware even before we started, that we would not finish a story. If we cannot make such judgements even after a couple of sprints, the sprints are not teaching us anything. If we are not gaining a more accurate estimate of our team’s capability, sprint by sprint, we are not being Agile. What obstacles keep us from understanding our team’s capacity to deliver? Investigate that.

Sometimes we misread a user story. We clearly see the story only after working on it for a couple of days. At this point it should become clear whether we will finish the story or not. This kind of early feedback is the cornerstone of the Agile way. If you become aware of an out of control story only at the end of a sprint, you are not being Agile. Why is this feedback not happening? Or is it happening, but the information is worthless? Perhaps your team is dissembling, and the scrum master cannot tell fact from fiction. Look into this.

Velocity – Weather or Climate?

It is not hard to see why we fixate on which sprint earns a partially completed story’s points. We are trying to figure out how much our team can deliver in a sprint; the so called Velocity.

Do not get too hung up on Velocity. As Mike Cohn of Mountain Goat Software points out, Velocity is characterized by a dichotomy that is very much like the one between weather and climate. On any given day, weather can be good or bad. You can make valid generalizations about the weather of a particular location, only after observing it over a large span of time. We have a word for that. Climate. Think of Velocity as climate, not weather.

The number and size of user stories that you start and finish within a single sprint, will vary from one sprint to another. Don’t worry about it too much. Over several sprints, you will get a good measure of how much work you can do. Over several sprints, Velocity will reveal itself.

Here are three slides from Mike Cohn’s Scrum Master training, which also make the above point.

Focus on learning from the trials and tribulations of each sprint.  Address these issues as you become aware of them.  Velocity will take care of itself.