Team velocity dramatically slows down to the end of a sprint

Question

I have noticed that team velocity sometimes becomes "negative" near to the end of a sprint. There's few trivial story's/bugs left but they took extraordinary effort to finish. Team seem's not to be exhausted. But this is always endangers and shifts delivery date. What i have tried:

1. Micro-control - gives a little boost, but stress people, and against agile practices
2. DYI - works but only if you know how
3. Reduce the sprint backlog capacity to have a cooldown period where team could set all the things right. - Not working
4. Introduced a redline, something like internal dead line where all of storys should be closed with all non trivial bugs. - Not working
5. Shifted release to middle of a next sprint, and applied firefighting team who FINISH OFF tasks left. - Works but nobody want's to finish others job.

None of the listed methods are 100% working or satisfactory from stakeholders/management point of view.

Any ideas on nature of of things or suggestions on how to get rid of the issue?

Answer 1

You're using the term velocity in an odd way. The velocity is the amount of effort that a team can put into developing stories per sprint. It's usually measured in story points. The average of the velocity serves for release planning or to guide during Sprint Planning how much work can be done in one sprint.

It sounds more like you're talking about some kind of Burndown Chart. Here it's important to distinguish if you're looking at a Task Burndown Chart or a Story Burndown Chart.

If the velocity becomes negative or slows down dramatically that probably means the Burndown Chart is going up rather then down. If that's the case that suggest two things:

• You've initially underestimated the amount of work
• There are impediments which make it impossible to get the work done

Answer 2

There's few trivial story's/bugs left but they took extraordinary effort to finish. Team seem's not to be exhausted. But this is always endangers and shifts delivery date.

and

team understands that there is a problem. But thinks it's a natural order of things and don't knows the root cause and prefers to leave things as is.

Is your team by any chance full of personality types who depend and/or thrive on the pressure of a deadline in order to get things done?

It doesn't sound like they agree that there is a problem. A "problem" is not really compatible with the "natural order of things".

The only process solutions I can think of have already been mentioned: internal deadline, strict WIP limit, sequential story delivery (my team calls these "sub-sprints").

But it sounds like what you really have is a problem of motivation, and that endangered & late deliveries are a problem for you but not for them. So how can you make them care? Do they experience any negative consequences for late deliveries? Can you provide rewards for on-time or early deliveries? Can you point out (or have someone else point out?) the risk to the team's reputation among upper management if this is their pattern?

Answer 3

Terminology Housekeeping

Velocity should be understood as a measurement of "Done" software increment the Development Team produces. This is because it is worlds more important to measure this than "velocity" of task, workflow step, etc.

Now that we're talking "Done" i.e. Definition of "Done" in Scrum, let's talk about how to reduce the risk of stuff not getting "Done" at the end of the Sprint. In short:

Ruthlessly Decompose Large Bits of Stuff into Smaller Bits of Stuff

The Scrum guide includes effort in the four aspects of each Product Backlog item. The size of work is related to this measure. I have noticed a correlation between risky and large bits of work. To reduce the likelihood of work not getting "Done," constantly break down work at the top of the backlog into smaller and smaller bits. I very much like this article for good decomposition techniques

Get Smaller Bits of Stuff "Done" Faster

Make Product Backlog Items small and valuable (also lookup the INVEST criteria for more help on creating PBI's).

Focus maniacally on getting small items done quickly before moving on to new ones i.e. keep work units small and ruthlessly limit WIP until optimal WIP can be observed. Watch this video to better understand what optimal WIP looks like:

https://www.youtube.com/watch?v=W92wG-HW8gg

What does this accomplish?

Risk for each increment of software is address and eliminated well before Sprint end. Therefore, the risk encountered at the end of the Sprint will be reduced, and Development Team forecasts will get more accurate.

Answer 4

When I am reading "near to the end of a sprint" it means that your sprints are too long. You need to shorten your sprints. That's the main thing that you need to focus on. You have the answer within your question.

Answer 5

You gave quite a clear explanation of what happens, and of the actions you've taken to solve the problems, but we're kind of missing why this is happening, so it's difficult to give an answer.

Do you have any insight on this? Have you tried to tackle the problem during the retrospective? What is your role in the process?

-- update based on this comment --

team understands that there is a problem. But thinks it's a natural order of things and don't knows the root cause and prefers to leave things as is

I might be wrong, and I 'm probably missing something (for example it's still not clear what your role is, I suppose you are the Scrum Master), but what I would do in this case is:

1. Engage the team in a discussion around the problem, and if necessary bring some stakeholder in to bring their point of view. If the problem exists then it should be tackled, despite the fact that they may consider this important or not
2. Try to put in place some actions to allow the team to deliver each story sequentially. This may lead to an even worse scenario in the short-term, but at least it allows you to have more insight of where the problem is, and take appropriate action

In any case I'd work on communication to let all the people involved have a shared understanding of the situation.