Should you reward based on overall project completeness or velocity?

Question

The development team I'm in has been working on a VERY large project for months now and we recently started to implement a kanban board with agile practices into our process. We have seen MASSIVE improvement in our throughput! Its so exciting! But we have one struggle right now. We have a total ticket count for the project and our supervisor has given us incentive(candy and popcorn boxes) for when we get down to 100 and 50 tickets. It at first felt like a great idea but it feels like new tickets are created just as fast as we can resolve them, and its making the team feel worse about our progress. So heres my question:

Should you reward based on overall project completeness or velocity? And if completeness how do you make that feel more reachable?

Answer 1

Ah, you're shooting a moving target and expecting people to pretend it was standing!

You should make up your mind on a target. If remaining ticket count is a metric, it's unfair to add tickets, especially externally, in a forced way.

In SCRUM when a sprint is planned the team commits to its content at the start, unanimously. From that point the content can only be changed by the team itself (or the sprint cancelled). Otherwise you kick the team out of control, and kill all hope of true commitment.

You may adopt some similar idea. Or drop that targeting system, and just reward healthy effort put to solve problems, accepting that you had X amount of progress, but in the meantime might have extended the project scope by more than that.

On the other hand I do suggest preventing scope creep by using milestones: add new stuff to the next milestone and you may even keep the original metric score. After the milestone is done you can plan the next one.

Answer 2

Are you incrementally delivering the system to production? If not, I would begin, deploying even small parts of the system can help morale, and build a good relationship with the customer. Doing these incremental deliveries will give the team a shorter horizon to focus on, helping the goal to feel more reachable.

As far as rewards go, I would not reward based on velocity, it brings to mind an old Dilbert cartoon where the boss states he will give bonuses for each bug fixed, after a bit of celebration, Wally proudly declares, "I am going to go code myself a mini-van". Rewarding based on velocity I feels sends the wrong message to the team, we value metrics over working software.

Cheers!

Answer 3

If you have committed to using a SCRUM methodology - you would have a fixed Sprint Backlog. Its well established that, you should keep the backlog frozen for the duration of the sprint.

If there is an exceptional case for a ticket to give you greater RoI by including it in this sprint after the backlog was frozen - then it makes sense to modify the backlog. However, if you keep adding items to a backlog during the sprint just because the items are being cleared out at a good velocity - it masks the progress and undermines the process.

During the life cycle there would be many tickets created and closed and the number would keep increasing or decreasing during this period.

Count of Tickets solved by themselves dont offer a view of complexity,criticality involved in the issues solved. If you get stuck on two complicated tickets over a 2 week sprint - by the metric of ticket counts closed, you would be pretty badly rated.

Ticket count should not be the metric. Incentive should be given to bug free feature releases in increments. And these increments should be planned for a sprint and the backlog frozen.