Scrum, grounded in the business
A team can be working at full speed and still not be moving toward what the business really needs. That is why, for me, working with agile methodologies starts well before organizing a sprint.
When we talk about Scrum, it is common to think of meetings, boards, tasks and weekly deliveries. But after working coordinating development teams and managing digital products, I have learned that none of those things help much if we are not clear about what we are trying to solve.
You can have a very good team, build features and meet deadlines, but are we building what the business really needs?
That is where I find the value of working with agile methodologies. It is not about following a meeting calendar or filling a task board. It is about keeping the team connected to an objective, making decisions on time and learning from what we build.
This is how I approach project management using Scrum.
01. Understand the business
Before thinking about features, we need to understand the problem.
Every project starts with a need, but it does not always arrive well defined. Sometimes the client has a fairly clear idea of what they want to build, but we still need to understand why they need it and what they expect to achieve.
That is why my first step is to talk with the client, the stakeholders and, when appropriate, get close to the users. I need to understand how the business works, where its difficulties are and which opportunities we want to address.
This lets us avoid something quite common: starting to develop a solution without having truly understood the problem.
02. Define what we are going to build
Ideas have to become decisions the team can carry out.
Once we understand the problem, we need to translate it into something concrete. This is where the functional definition work begins: organizing the needs, identifying features, writing user stories and building a roadmap that lets us see where we are heading.
Not everything can be built at once. That is why, together with the team and the stakeholders, we work on prioritizing what makes the most sense to tackle first, considering the value for the business, the needs of the users and the technical possibilities.
A good backlog is not an endless list of things to do. It is a tool for making decisions.
03. Build in sprints
Working in short cycles lets us stay focused without losing flexibility.
With the priorities defined, we organize the work into sprints. The team takes a set of user stories and works to turn them into features we can review.
My responsibility as Product Owner is to keep that direction. I coordinate the work, help solve blockers, clarify requirements and keep the stakeholders informed about progress and the decisions that come up along the way.
Things do not always turn out exactly as we planned. Technical difficulties, new needs or changes in priorities can appear. What matters is that we can address them without losing sight of the product’s objective.
04. Review what we are building
A feature being developed does not necessarily mean it is finished.
An important part of my work is reviewing that each user story meets what we defined. For that I take part in the QA process, checking the deliverables against the requirements and the expected criteria.
This lets us detect differences between what was requested and what was actually built, fix problems and keep small errors from piling up as the project advances.
It is common for a developer to say that something is almost ready, or technically ready. But “ready” means it works and that all of us have reviewed it, not only the person who built it. That detail that does not meet what was expected usually shows up only in the review, and avoiding it takes judgment: the experience to tell apart what looks finished from what really is.
I prefer to stop and review a feature before calling it finished rather than discovering later that we built something different from what we needed.
05. Learn and adjust
A plan gives us direction, but it does not have to be set in stone.
At the end of each cycle we review what was built, talk about progress and assess what we need to adjust.
Sometimes we find that a feature needs more work. Other times we understand that a priority has changed or that there is a better way to solve something.
The good thing about working iteratively is exactly that: we do not need to wait until the end of the project to find out whether we are on the right track.
Each delivery lets us learn something and use that learning to make better decisions in the next cycle.
What I took away
Over time I learned to recognize some warning signs that can affect a project long before they become a problem.
Unclear priorities, decisions without defined owners or expectations that were never agreed. They seem small at first, but they can end up generating rework, delays and frustration between teams.
Today I try to address these situations from day one. I prefer to ask an uncomfortable question at the beginning than to have to explain a problem at the end.
For me, working with Scrum does not simply mean organizing tasks better. It means building a way of working where the business, the team and technology can move in the same direction.
Because in the end, it is not about how many features we manage to deliver in a sprint, but about how close we get to solving the problem we set out to address.
Building well also means knowing what is worth building.
