Competition based backlog

The past two days I have been at a Agile Scrum gathering. One of the speakers was talking about how poorly the backlog gets managed. I was listening to him and thought about whether it would be beneficial to have a competition based backlog.

There are two factors in getting the backlog right. Incetivising your developers to want to burn down the backlog and to incentivise your product owner to actually manage the backlog consistently.

I think that the first factor is easier addressed than the second. One could assign rewards to story points or use an alternative reward system on the backlog. High rewards are at the top and developers compete, somehow, for the reward points that are assigned to the tasks in the backlog. With these points they could purchase days off, longer lunches, other benefits that they would possibly enjoy. What might happen is that you could see a market developing for reward points.

More thought needs to be put into how the developers would compete for the backlog entries. Although from a HR perspective, this could have negative effects on the team. Only the people who thrive on competition will perform. The other side effect would be that it would make rewarding the team more difficult as the focus is on the individual. Personally I prefer team-based work for rewards and incentivising. Teams perform better than individuals and I would shy away from this idea purely for that reason.

The idea is in its infancy. I have no idea how to incentivise the product owner or other stakeholders to engage more thoroughly with the process. In hindsight this might not be a wise option. I would think it would work for teams that are highly competitive and where individuals are valued more highly than teams.

  • Pingback: Agile leadership as a team sport | Andrew van der Westhuizen()

  • Adrian

    Hi Andrew

    I’m looking at this as well.

    Agreed, incentivising the team over individuals makes more sense. We have a system that I am looking at proposing to our managers at my company. It is based on the team achieving the sprint commitments over a period of 10 sprints (or 12 to make this a quarterly thing). It’s a team award. It can’t be money, but I’m still worried it’s not intrinsic enough for techies, and that it may deviate from long term quality.

    It would be great if we could chat re. this.


    • Your concern is on long term quality of the product or software. If that is the case, you will have to work it into your metric (story points, for example). Story points should have a review on quality achieved, or the testing should adjust the story points retrospectively to address bad quality for instance. Essentially you want to incentivise two things, quality and throughput. Unfortunately, they are inversely proportioned to each other.

      Incentivise quality and you can expect throughput to take a knock, or throughput and quality will take a knock. Can either take the hit? I do not know your business and I do not know what your order winner is, or what your potential order disqualifier is. You can incentivise both and hope to expect better results, but it would be important to not set unrealistic goals for the rewards.