Here’s a very simple tracking mechanism for physical story cards that your team can use to learn more about the proportion of time you spend on different types of work. One of our product development teams has used this approach for tracking time spent on things for at the last year and a half. As a team, we don’t typically do any deep analysis of the data gathered but it does help us understand what’s going on when our velocity dips. This data also helped the team push back on minor support requests over new features when this became an issue
Here's how it works. We use coloured cards to represent different types of work:-
- White cards are used for stakeholder facing stories. Blue half-cards are sub-tasks for stories and don’t get counted separately
- Green cards are technical tasks such as upgrades of infrastructure
- Red cards are support tasks such as bug fixes and data requests
- Gold cards are developer research. Although we don’t represent these using physical cards, instead we put them on our team calendar so that we know which day they’re planned for. We also use this team calendar to track the time spent in meetings.
The different colour cards have swim lanes on our team board and get prioritised in different meetings. Stories are prioritised by stakeholders every week. Red and green cards are prioritised by the team on a weekly basis.
At standup time, we apply a dot to the cards on the board based on how many developer days were spent on them the previous day. One dot represents a single developer day so cards that were paired on get two dots per day, etc. Then on Friday, someone from the team crosses out the dots on the cards and sticks the data into a shared spreadsheet. From this information, we can see that we rarely spend more that 50% implementing user stories and that we have spikes in green and red when there are outages. It’s also good to see whether we’re ensuring the developers are making time for their research.
You don’t need any special stationery to get started because you can draw dots with a marker pen. We additionally use a date stamp to mark when story cards get started and finished. We also have a record card box to put completed stories into.
I guess to Kanban folk this might sound like we have no defined classes of service and corresponding limits. We find that pair programming and small team size puts enough of a limit on these for us. In a team with 3 developers we can only run one pair per day on features/stories and then the person who's not pairing figures out whether to dedicate the day to research or a mixture of green/red cards.