6

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?

Improve this question
5
  • 18
    If tickets are coming in faster than you can handle them, and the team has already demonstrated dramatic productivity improvements, then the supervisor is trying to squeeze blood out of a turnip.
    – Robert Harvey
    Jun 3, 2013 at 16:39
  • Yeah, agile methods are supposed to produce sustainable pace over long time, strip-mining should be strictly avoided.
    – Balog Pal
    Jun 3, 2013 at 16:50
  • 3
    Has the increased throughput introduced more bugs or more feature requests?
    – JeffO
    Jun 3, 2013 at 19:30
  • 3
    Your supervisor needs to be careful with their choice of measurements/incentives. It can easily devolve into gaming the system (e.g. Skimping on quality or creating smaller tasks to meet some velocity metric).
    – jhewlett
    Jun 4, 2013 at 0:18
  • 3
    @jhewlett It almost sounds like that may have already happened. Perhaps they really really like candy and popcorn boxes?
    – Izkata
    Jun 5, 2013 at 1:06

3 Answers 3

Reset to default
8

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.

Improve this answer
1

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!

Improve this answer
0

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.

Improve this answer

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.