All-In-One Task Management System

All-In-One was a team project, but the real project for me wasn't the code, it was learning how to run a software project properly. I rotated through both Product Owner and Scrum Master roles across sprints, and that's where most of what I actually took away lives.

Running as Product Owner meant translating customer requirements into user stories with acceptance criteria, using the INVEST framework to check each story was independent, valuable, and testable, and keeping the backlog DEEP so it stayed detailed, estimated, emergent, and prioritized as things changed. The biggest lesson there: think like the end user, not like the developer. It's easy to build what you assume the client needs. What actually matters is checking that assumption against what they say they need, and adjusting when the two don't match, which happens more often than you'd expect.

Running as Scrum Master meant facilitating daily standups, sprint planning, sprint reviews, and retrospectives, and keeping the team aligned without slowing anyone down. Standups stayed strict at fifteen minutes: what you did, what you're doing, what's blocking you, and any real technical discussion got pushed to a separate session so it didn't balloon. Sprint reviews were where we walked stakeholders through what was actually done against our Definition of Done, and retrospectives were where the team said what worked and what didn't, out loud, on the record.

We ran everything through Jira for the backlog and sprint tracking, and Confluence for documentation and sprint notes. I learned test-driven development properly here: write the test first, watch it fail, write the simplest code that passes, then refactor, then rerun the whole suite. We backed that up with unit tests, system integration testing, and user acceptance testing before anything shipped, because catching a bug in review is a lot cheaper than catching it after the client sees it.

The other thing that stuck: a project runs a lot smoother when the team agrees on a standardized tech stack, frameworks, and languages up front, along with formatters, linters, and naming conventions everyone actually follows. Sounds small until you're the one reviewing a pull request full of inconsistent style, trying to figure out if the logic underneath is even correct.

This is the project that ended up mattering most for my current role at Accenture. Acting as the bridge between developers and the business side, translating what a client actually needs into something engineers can build, is basically the job now, and this was the first place I practiced doing that for real.