2

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?

12
  • 2
    How long are the Sprints? Jan 26, 2016 at 11:34
  • 6
    What do you mean the velocity slows towards the end of a Sprint? Are you saying that you measure velocity on a daily basis and hope to maintain that momentum? If so that seems extremely dangerous. Velocity is a measure of the team's output over the entirety of the Sprint Box. The daily fluctuations are less important than the consistency of velocity from Sprint to Sprint. Jan 26, 2016 at 14:44
  • 6
    My additional fear is that what you are actually referring to is work started, partially completed and then left languishing despite the bulk of the development completed. That indicates to me that your Definition of Done is not being adhered and stories are not thin-slices of value that are being driven to completion. Can you describe a typical user story that your team leave uncompleted? Jan 26, 2016 at 14:45
  • 4
    That is not a user story; that's a fully integrated feature request. The equivalent would be "As an English speaker I want to see all of Amazon in English." That is not a user story. Also "a better user experience" is not a business outcome. Jan 28, 2016 at 15:56
  • 3
    I would suggest returning to first principles and studying the Patterns for Splitting User Stories located here. agileforall.com/2012/01/new-story-splitting-resource Jan 28, 2016 at 15:58

5 Answers 5

2

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
3
  • @Alexander Averchenko could you please verify what you mean when you talk about a) velocity and b) velocity becoming negative. Jan 26, 2016 at 15:00
  • Thanks for theory update, "negative" is a hyperbole. We are using small story's to have daily burndown update. So i can see how much story's closed daily to have duplicate source of project health info in addition to daily meetings. Jan 27, 2016 at 8:52
  • 5
    I honestly would not worry about "daily burndown" and focus the team on a symbolic victory - as a cross-functional team get them to move one entire story into the Done column before doing anything else. Jan 28, 2016 at 16:00
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?

2

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.

2

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.

1

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.

4
  • I guess if i knew why, i wouldn't go here to ask. I am hands-on PM/SM. Retrospectives gave nothing for this issue. Jan 26, 2016 at 10:23
  • Could you elaborate what "gave nothing" means? Does the team see the problem but it's unable to understand why or it's not even perceived as a problem? The thing is, without even the slightest knowledge of why this is happening, trying to find a solution is like shooting in the air hoping that a bird will cross the path of the bullet. And even if you find a solution you'll not be able to understand why it works...
    – mamoo
    Jan 26, 2016 at 10:28
  • It means that 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. Once again, if i would know why it's happening i could find a solution. That's why i came here to ask peoples who were in similar situation and find a cause. Jan 26, 2016 at 10:39
  • This is already something, I'll update my answer based on that. :)
    – mamoo
    Jan 26, 2016 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.