Recently, I answered a question about how to do the story point accounting when a user story spans multiple sprints. The scrum team had several user stories that were started in sprint one, but completed in sprint two. Since velocity is a measure of the rate at which the team is delivering stories, we found it best to count all the points for a story in the sprint in which it is completed.
Now let’s examine the question from the point of view of a scrum master. A scrum master’s job is to help the team improve and progress toward the goal of becoming a continuously-improving, high-performing, self-organizing, possibly-over-hyphenated scrum team.
The question is being asked because the team members are feeling some pain. They have worked hard on four stories, but only completed one. This doesn’t feel good and they are looking for a way to alleviate the pain. The quick fix is an accounting trick to give the team ‘credit’ for working on, but not delivering, their stories. This only accommodates the team’s dysfunction. A scrum master will want to help the team find and fix the root causes of the pain. In this way, they may fix the problem instead of perpetuating it.
Read the full article…
How should a scrum team count the story points for user stories (product backlog items) that are started in one sprint but completed in a later sprint? This question comes up frequently and has surprisingly deep implications. It also has a simple answer. Let’s dive into an example that a client sent me.
I was inspired to create a retrospective game for agile teams, based on the game Dixit. 
A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate, and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.
A client recently contacted us for guidance regarding managing individual performance in a scrum environment. This is a growing company that successfully adopted scrum a few years back. They asked me what they should do with a scrum team member that is not performing. Should they implement a performance management system, and if so, how?