Tools: Building Sprint Tracker #01

Introduction ## Step 1 – Starting from a spec (with Kiro) This project starts from something very simple: a Google Form that collects sprint check‑ins and feedback, all ending up in a single spreadsheet. Inside that sheet is a mix of important signals – who has finished their work, how confident people feel, and where someone might be struggling – but in its current form it’s hard to act on quickly. The aim of this series is to turn that spreadsheet into a small, reliable backend that makes those signals easier to see and work with. I also want to use this project as a chance to experiment with spec‑driven development and with Kiro – an AI‑assisted IDE that helps me write requirements, designs, and tasks before I touch the actual implementation. Before writing any code, I asked Kiro to help me describe the system I wish existed. Instead of jumping straight into implementation, I worked through a spec‑driven flow: capturing requirements, shaping a design, and breaking things down into tasks I can actually build. Kiro sits inside my editor and acts like a structured copilot: I can say “I have this form and I want to turn it into a marking/feedback tool” and it helps me turn that into a requirements document, a design with clear components, and a set of concrete tasks I can pick up one by one. It feels less like “write some code with AI” and more like “design the system together first, then implement”. For this project, that ended up as three files: At this point I have a requirements file, a design document, and a generated task list – but still no running code. In the next part of this series, I’ll start turning that written design into a concrete architecture and the first implementation steps. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - requirements.md – what the tool should do, who uses it, and the acceptance criteria. - design.md – how the system is put together: main components, data model, and the AWS pieces it will use. - tasks.md – a checklist of implementation steps, each tied back to one or more requirements.