Should I Use Tech Cards in Agile?

Tech Cards are used to set aside time during a sprint for research, design, solution exploration, and even prototyping to help refine the solution for the user story. Tech Cards are sometimes referred to as “Spikes”. Tech cards do not produce deployable code or create business value. Tech cards or spikes are used to clarify the acceptance criteria for a user story.

Using tech cards because the team doesn’t understand the acceptance criteria can be problematic. The team’s working agreement contains the Definition of Ready (DOR) which outlines the criteria to meet for a card to be accepted into a sprint.

Teams can move cards into a sprint without having good acceptance criteria. This slows velocity down because the card is now taking up time and resources during the sprint that could have other wise be used to deliver business value. Ensuring the acceptance criteria or the “what” of the user story is fully understood and agreed to by the team before starting the sprint is essential to keeping your velocity. 

That doesn’t mean there isn’t a need to do research or prototyping of the user story solution by the team. This can be very beneficial when a team has encountered a completely new solution that they have little experience with. Let’s say you have acceptance criteria that is asking for facial recognition for login. Your team has never worked with that technology and doesn’t have any experience with it. A tech card is created to give the team time to put together research and potentially a prototype on how to best meet the acceptance criteria. 

So all tech cards are bad? Let’s look at it from a different perspective. It’s the reason why you are using the card that is important. If the reason the card was created was due to a user story being pushed into a sprint without good acceptance criteria, then that could indicate the acceptance criteria . If tech cards are being used to set aside time for research, then tech cards help create more organization and structure. Setting aside time for the team to learn and prototype is a good thing so you are not piling on to the teams work load causing team burnout or reduced velocity.