Carrying items over from one sprint to the next

Question

Question: Carrying items over from one sprint to the next

Answer: Yes

Scenario: I am a new scrum master on a team and we have just completed our first sprint. I was not here when the team planned the sprint but We planned to complete 73 Story Points. I calculated our velocity is about 53 story Points (Previous Sprints) and some team members was off during December and one person had a child. I am not sure why they planned full capacity with those people on leave.

Task 1 : 8sp - Done
Task 2 : 20sp - WIP
Task 3 : 8sp - Done
Task 4 : 5sp - Testing in Progress
Task 5 : 8sp - WIP
Task 6 : 8sp - WIP
Task 7 : 8sp - Testing Failed
Task 8 : 8sp - WIP

The sprint ends tomorrow and there is a bunch of stories going to the new sprint. As mentioned I calculated the team velocity as 53sp (Previous Sprints), With the work in WIP/Testing Failed it adds up to 21 (If testing passes on 5sp item). They do buddy programming if someone is stuck, which is awesome.

1. Do I carry those over to new sprint and if it gets completed mid sprint we just add stories to the sprint from backlog? - I say yes that is correct.
2. My velocity will be influenced by data such as above, can I work out velocity by: Remove highest (This will be next sprint if we carry items over) velocity and lowest velocity, count the rest and divide by number of sprints?

3. In the current sprints retrospective I will mention the following:

   a. Cross skill - Need to work on that

   b. We need to plan better and keep leave in mind

   c. We need to speak up during the sprint if we wont make the sprint, then we can make necessary adjustments

   d. Remind them of scrum values.

   e. Cant we make tasks smaller?

Do you perhaps have any other suggestions to improve our planning, committed items to reach our target velocity and am I on the right track?

Answer 1

There is a lot in there, so let's take it item by item.

First, what do we do with incomplete work?

It goes back to the product backlog. Technically, the product owner decides if it is still important to do in the next sprint. It is completely reasonable for them to say "Nope, that's not what's important anymore, this other thing is." True, most of the time they will be pulled into the next sprint, but it isn't a given.

Next, partial story points is an antipattern. It rewards the behavior of not completing work, which goes directly against agile principles (Working Software is the primary measure of progress, specifically). The whole story is done or it isn't.

Average Velocity

I usually calculate average velocity the same way - it gets rid of outliers. If you have a fairly consistent velocity, you could also just use a median average instead of the mean - accomplishes the same basic thing. It's just important to remember that story points are, by design, imprecise. When we apply math to anything, sometimes we create the illusion of precision and we need to be on the lookout for that.

Retrospective

These all seem like completely valid points, but remember as scrum masters we can't wave a magic wand over the team and make them better. The improvement the team finds on their own will stick much better than the one you tell them to make. As a facilitator for the retrospective, can you create a format of the conversation where they are likely to find one or more of these on their own?