Scrum for a team of one: requirements and weekly sprints in my master's final project

Scrum for a team of one: requirements and weekly sprints in my master's final project

Scrum is designed for teams: a product owner, a Scrum master, developers, a board everyone updates. My master's final project, a multiplatform e-commerce app with an Ionic client and a Laravel backend, had one person filling every role. I still organised it in sprints, and looking back at the notes I kept, the useful question is not whether that counts as "real" Scrum. It is which parts of the method still pay off when you are alone, and which ones turn into ceremony for its own sake.

Why a to-do list was not enough

The alternative to an iterative method is the classic waterfall sequence: requirements, design, implementation, verification and maintenance, each phase closed before the next one starts. For a project like mine its problems were obvious from the start. It is slow, and it assumes the requirements are known and stable up front, when in practice they change as you build and discover what the product really needs.

Scrum's premise is the opposite: deliver in small pieces, learn, adjust. Even with no customer giving me feedback every week, I was my own first user, and every week of building changed what I thought the app needed.

Requirements engineering, solo edition

Before planning sprints I went through the classic requirements phases, adapted to a project with no external client:

• Inception: understanding the problem and the kind of solution: a shop that works on mobile and has a proper back office.
• Elicitation: turning that into explicit functional and non-functional requirements, with a defined scope.
• Elaboration: modelling functions and scenarios with diagrams. For me that meant the database design (which I moved to dbdiagram.io because it was easier to read) and Excalidraw sketches of the admin screens.
• Negotiation: with no client to negotiate with, I negotiated with the calendar. Features that did not fit went to an explicit "optional for now" list instead of disappearing.
• Specification: the requirements written down, functional and non-functional, as the reference for the rest of the project.
• Validation and management: checking the product against that reference, and tracking changes as the requirements evolve.

Validation is the phase that suffers most without a team. Nobody else reads your specification and asks the awkward question. The partial fix I found was the weekly review against the backlog, described below.

The backlog: four blocks and an "optional for now" list

The product backlog was a single note split into blocks: client screens (Ionic), admin screens (Laravel), client–server connection, and tests. Under the client block sat an explicit sub-list called "optional for now": social media links, phone support, a messages section, privacy policy and terms of use, translations, and sharing products on social networks.

That sub-list did more for scope control than anything else. A feature in "optional for now" is not rejected and not forgotten; it is consciously postponed. It lets you say no to yourself without losing the idea.

Weekly sprints instead of two-week ones

Scrum's usual guidance is sprints of one to four weeks, with two as the common standard. I used one-week sprints, each a note named after the ISO week (2024-05, 2024-06 and so on) and linked from the backlog. My notes cover the sprints from early February to mid-April 2024.

Each sprint note is a short list of concrete tasks with a start date and a completion date. A typical early sprint: tab bar, search bar, add to cart and to favourites, and the cart itself. Later ones: creating the Laravel models and seeders, routes and controllers, pagination and live-filtered tables in the admin panel, PDF and Excel exports, and image handling on the server.

A week was the right length for one person. It is long enough to finish something visible and short enough that a bad estimate costs days, not weeks. And the sprint backlog stays fixed during the sprint: new ideas go to the product backlog, not into the current week.

Which ceremonies survived

Scrum lists five ceremonies: backlog grooming, sprint planning, sprint review, retrospective and the daily stand-up. Alone, not all of them made sense.

• Sprint planning survived intact. Writing the week's note was the planning: a realistic, achievable list, not a wish list.
• Sprint review became checking items off with their completion date. The dates turned out to be more useful than the ticks: they show which tasks took a day and which dragged on.
• Grooming happened whenever tasks moved between the product backlog, a sprint and the optional list.
• The retrospective shrank to a "doubts" section in some sprint notes. One example: whether the orders table needed to store a price, given that it can be computed from the order lines. Writing down the question and the answer (not strictly necessary, but worth keeping for efficiency) is a retrospective in miniature.
• The daily stand-up did not survive. Asking yourself what you did yesterday and what you will do today adds nothing when the start date of each task already answers it.

I also created a Kanban board with To do, Doing and Done columns. It stayed practically empty. For a team of one, the weekly list was the board.

Unfinished work is information

Not everything got done. Email verification and mail configuration for the API appear in one sprint, are carried over to the next one, and stay unchecked. Seeing that in the notes is not a failure of the method; it is the method working. The task was visible, it was consciously deprioritised in favour of the admin features, and it never expanded the scope without me noticing.

Documentation went into the sprints too. Writing the theoretical framework of the thesis, correcting it, and planning its chapters (planning, implementation, results and future work) were backlog items like any other. Treating writing as work with a deadline, rather than something left for the end, is probably the habit that made the biggest difference.

Learning the vocabulary after the practice

There is an irony in my notes: the summary I wrote about Scrum (waterfall versus agile, sprints, artefacts, ceremonies, roles) is dated April, in one of the last sprints I recorded, while the weekly sprints started in February. I practised the method before I had formalised it, and formalising it later mostly gave names to what was already working.

The project got the highest grade (Matrícula de Honor). I would not credit that to Scrum. But for a solo project with a fixed deadline, a weekly sprint, an explicit "optional for now" list and dates on every task are the cheapest way I know to keep the scope under control.