tl;dr — Pivotal Tracker is the be-all and end-all of software development tracking. As a developer, I don't hold myself accountable to any work that isn't wri

tl;dr — Pivotal Tracker is the be-all and end-all of software development tracking. As a developer, I don't hold myself accountable to any work that isn't written down in a user story prioritized by my product manager — the only person to whom I answer. Requirements don't come from meetings; they come from this backlog. I take work off the top, and when it's delivered I can easily filter into a historical view of my accomplishments (isolated from amongst my team's). Within a single feature, I use TDD to orient myself forward: a test that's failing tells me what _technical_ requirement stands between myself and delivering the feature. If I am working on something that doesn't lend itself to testing — i.e. dev-ops — I will keep a context-stack of sticky notes that churns hourly, and is tossed at the end of the day. Above features, Tracker's concept of Epics allows my team to measure progress on new wings of our users' journey, but I don't think at that level on a daily basis; only periodically when asked to wear a UX hat as part of a design exercise. For the fuzzy things around the edges, I do use a half-assed bullet-journal. It mostly comprises questions like "why am I in this meeting?" or "when will this be written into a user story?" I also use 750words.com to "take the edge off", some days. I fill it with stream-of-consciousness reflections that may later prime and inform my contributions to process-design exercises. Tracker will appear heavy-handed for a team without a dedicated product manager who relies on developers' estimates to inform their sovereignty over backlog priorities.