Index Cards have become an indispensable tool for a software development team practicing agile. There are a host of good sites with information on strategies for and benefits of utilizing index cards.
Agile teams use Index Cards for a variety of reasons, including:
- helping with iteration planning
- assigning tasks and then tracking developer assignments
- recording task estimates
- as one component of the team's Information Radiator.
- reminders of the conversations between customers and developers around the definition of user stories.
The cards are an excellent visual representation of the health of the iteration. A majority of cards still in the "to do" with the end of an iteration pending usually means the team is behind schedule. A scarcity of cards means the developers will soon run out of tasks and so the backlog had better be up to date. Cards also work well as a great tool for facilitating the assigning of work (more specifically, allowing developers to assign themselves individual tasks). On the JIRA Studio team at Atlassian, back in "Ye Olden Days" (circa 2008) we used to use actual physical index cards, stuck to the team white board with blu tack. The use of physical index cards does have drawbacks:
- Duplication of effort
- Data from cards and issue tracker being out of synch
- Bad handwriting leading to incorrect implementations
- Tons of old index cards lying around
Greenhopper is key to being able to do agile project management. We use the virtual cards for the traditional tasks of iteration planning, capturing requirements, and capturing acceptance criteria. The use of virtual cards allows for all of the functionality and advantages of physical cards, with the added advantage of better communication, and instant updates. Developers still "pick" their cards off the task board, track work on the cards, and place them in the "done" column when complete.
The JIRA Studio team was not a distributed team when we made the change to using the Greenhopper plugin exclusively. But now that one member is on another continent, the benefit of virtual cards to help with communication has grown even greater. Our Information Radiator is created with the virtual card wall displayed on a large monitor which also shows the current build status. Everyone on the local team can glance at the monitor for a visual representation of the health of the build and of the iteration, while the remote team member can view the exact same information in his web browser.
The synchronization of data is by far and away the biggest advantage of virtual cards, as an instant update of all information occurs whenever a card is updated. No more does a task get ignored due to a stray mark on the card. No longer does a developer waste time entering the same data onto the card and into JIRA. And the Team Lead no longer spends 30 minutes transcribing cards into JIRA issues or copying JIRA tasks onto cards in his chicken-scratch handwriting.
Greenhopper is integrated with JIRA Studio (and available as a plug-in for JIRA), so changes to a card are reflected in the JIRA issue, and vice versa. Moving the card to a new iteration, or new column on the board is reflected in the JIRA Issue. Changing the JIRA issue status to Assigned or Resolved immediately moves the card into the correct column on the Information Radiator. Almost as valuable is the ability to have multiple views of the information, without having to continually move physical cards. The cards can be viewed as a task board or a planning board, and sorted by priority, assignee, or a host of metrics.
Last, but definitely not least, the use of virtual cards mitigates a few of the dangers of agile.
