In the second part of this two-part series on adding game mechanics to Agile (read Part 1) processes, I want to discuss limiting the amount of cards a team has “in flight” at any given time.
By in-flight, I mean cards that are actively being worked on by developers. Limitation is defined as not taking another card from the backlog until there are less cards being actively coded than the limitation. Specifically, consider limiting this number to one less than the number of developers you have on your scrum team. There are several benefits to this technique. Here are three:
- It focuses the team – in many cases a team can start to drift in an iteration by working on cards that are near and dear to a specific developer or are “cooler” than other cards, neglecting features that were higher in priority on the backlog. Limiting the cards forces the team to focus on the tasks at hand and motivates completion of those tasks to open up slots for new cards to be taken from the backlog (perhaps including that really cool one someone had their eye on).
- It broadens the team’s knowledge – with one less card than developers, at least two developers have to pair up. This benefits the team with an increased pace of completion but what it also does is teach some of the developers something new that they couldn’t have learned through paired development.
- It speeds up your stand-up – the reduced number of cards ensure that there is always progress being made on all of them and that only those features get discussed. The pace of the daily stand-up quickens and only explicit deltas from yesterday’s status are reported. This is effective for teams of any size.
There are actually even more benefits than just these three but I figured this would be enough to at least get you try it. If you do (or already practice this way) please share your feedback in the comments.
[Jeff]