Wild card points

agile
Page content

Every now and then teams get work they don’t want to do for whatever reason:

  • It would be wiser to pay off tech debt before starting the new work
  • Another tech-stack is more suited for the work, but pipeline doesn’t support the tech yet
  • There isn’t much dev-work, but turns out regression testing is massive and one (of three) tester is on holiday and second called in sick

Wild card idea

A team gets 1 or 2 wild cards per year. The card belong to team members (dev, testers, QA) does not belong to product owner or scrum master.

Wild card are valid only a year. In January your team is allocated 2 wild cards, your team can’t move them to the next year if not used, they expire.

When product owner or a customer is pushing for delivery of 5 Story Points feature, a team is allowed to use their wild card and not commit to the feature next sprint. Not forever, just delay delivery of the feature until next time it is requested. If it is really important they will have to do it another sprint. It creates a 5 SP gap in the next sprint which the team can use to prepare themselves. Pay off tech debt, improve pipeline.

Use of wild card shouldn’t affect committed story points. You need to agree how to act and measure it correctly (sprint planning while sprint is in progress?). It leaves you extra points to deliver something else, something that the team wants, not something a customer wants.

Scrum master is a servant who acts on behalf of the team, this time they are a biased negotiator between team members and product owner or a customer. It’s in their best interest to let the team use the wild card when the team wants it.

Trade wild cards

If you have multiple teams working on the same product (squad-tribe organisation), you can let teams trade wild cards. Since wild cards belong to the whole organisastion and teams can delay some work for the whole organisation, it doesn’t matter which team uses how many wild cards, it matters what no more than number of wild cards is used in a year.

Note

This is more an XP/DevOps concept, than Agile/Scrum, but you can make it work inside a Scrum Team, just make sure you affect SP commitment as little as possible.