Blog post
The strategic role of the business analyst in Agile.
Posted by
on
March 12, 2026
Project overview
From analysis to PI planning.
My name is Niels Hammink, and I am a Business Analyst at Gorilla IT. One of my major assignments was supporting a project at GS1, where I applied structured, model-driven analysis to help align stakeholders, clarify requirements, and drive strategic decision-making across the organization.
If you didn’t know, GS1 is an organization that develops and maintains standards for identification in supply chains. If you look around and pick up any retail product, for example, a pack of raisin buns, you will see a barcode on the packaging. That barcode is based on a GS1 standard, and they are responsible for issuing these identification numbers and maintaining the global standards behind them.
At that time, Gorilla IT was asked to help GS1 with the realization of new functionalities in their customer portal, the system where clients log in and manage their products and related data.
Structured focus
Entering a structured way of working.
When we started at GS1, I quickly noticed that my role as a Business Analyst was different from what I had experienced before in Agile projects. GS1 operates in an Agile development environment where work is organized and aligned through quarterly planning cycles.
Personally, as a Business Analyst, that meant I was responsible for preparing and analyzing an entire quarter of work upfront. That responsibility felt both exciting and intimidating. If I did not prepare the analysis properly, the entire quarter would start with uncertainty. During the PI event, many stakeholders are present. If the preparation is unclear or incomplete, it becomes visible immediately. That pressure made the responsibility very real.
At the same time, I discovered that this structured way of working suited me very well. Having a clear PI event as a fixed milestone helped me enormously. I always knew what I was working toward. There was a clear end goal. Instead of focusing only on small sprint-level functionalities, I could see the bigger picture, the full initiative, the broader story.
In my opinion, that works much better. You are not just building small pieces; you are working toward something substantial. It feels more goal-oriented and meaningful. Structure gave me focus. It prevented analysis from drifting. It helped me work deliberately toward something significant.
Quarterly direction
The business analyst prepares the quarter ahead of the PI event, mapping priorities, dependencies, and uncertainties so teams can plan with a clear horizon.
Model-driven clarity
Models make relationships, boundaries, and impact visible. That reduces interpretation and creates shared understanding before decisions are made.
Alignment in one room
PI events bring stakeholders together around the same context at the same time, so trade-offs become explicit and planning becomes realistic.
Reality over enthusiasm
Analysis makes capacity, scope, and dependencies explicit, so decisions reflect what fits the quarter, not just what sounds promising.
Explore our services.
Artificial Intelligence.
With our AI solutions, we focus on measurable impact by building systems that automate work, support decision-making, and integrate seamlessly with existing workflows.
Business Analysis.
By exposing assumptions, clarifying priorities, and aligning stakeholders, our business analysts ensure the right problems are solved and decisions are made consciously.
Custom Software.
We design and build custom software that fits your organization’s processes, data, and goals, delivering scalable solutions quickly through a structured approach.
Visual clarity
Applying the All System Go method.
At Gorilla IT, we use the All Systems Go method. We advised GS1 to apply this same model-driven approach within their organization, meaning I had to lead by example. I was responsible for driving the method, demonstrating how to use it, and applying it consistently in my analysis work. A core element of that method is model-driven analysis, and this helped me personally a lot.
When I received a topic from a stakeholder, I started with the as-is analysis:
-
What is the current state?
-
What are the pain points?
-
What requirements already exist?
-
What constraints apply?
Only when the as-is state was clearly understood and validated I moved toward defining the to-be state.
What I really appreciated about the model-driven approach is that it helped me stay at the right level. It prevented me from diving too deep into details too early. By working visually and structurally, I could keep a bird’s-eye view of the initiative. I could see the full picture before zooming in. I also realized that I understand complexity faster when it is modeled visually instead of described in long text, which helps me surface the right questions about scope and impact, enabling stakeholders to make more informed decisions.
At quarterly preparation level, this high-level analysis was essential. The goal was not yet detailed specification, but scope clarification and impact understanding. What exactly are we trying to achieve in the to-be state? What is the size of this initiative? Which systems and stakeholders are affected? That structured, high-level analysis created overview and confidence.
Detailed preparation
From high-level overview to use cases.
Once the to-be state was defined at a high level, I moved into more detailed analysis and elaborated use cases. For PI events, I prepared enterprise architecture models and high-level process overviews, often in BPMN-style models:
-
The end-to-end process flow
-
System interactions
-
Stakeholder touchpoints
-
Functional boundaries
During the PI event, I presented these overviews to align all stakeholders: “This is the process. This is how the system supports it. At a high level, this is what the functionality will look like.” And since I had worked on that for weeks, I noticed that I could explain the initiative naturally, without heavy preparation, which gave me confidence.
After the main session, development teams refined the initiative in breakout sessions. With alignment already established, we could dive into use cases, derive user stories, and scope them clearly.
My goal was to have approximately 80–90% of the analysis completed before the PI event. There are always minor refinements needed, but that is normal. However, the foundation had to be solid and when it was solid, it showed. Instead of feeling stressed during the PI event, I felt prepared. The responsibility remained, but it became a source of confidence rather than pressure.
Driving direction
What this taught me.
Working this way reshaped my view on business analysis. The structured rhythm of PI events works very well for me. I like working toward something tangible and significant. It gives direction and purpose. Preparing an entire quarter may feel intimidating at first, but it creates ownership and clarity. The responsibility can feel heavy, especially knowing that many stakeholders rely on your analysis during the PI event. But when preparation is thorough, that same responsibility becomes empowering.
Model-driven thinking also helped me stay structured, see the bigger picture, and understand complexity faster. It prevented me from getting lost in detail and allowed me to move deliberately from the as-is state toward the to-be state. Moreover, business analysis, in this context, is not just about documenting requirements. It is about creating clarity before execution starts and shaping initiatives at the right level so that teams can build with confidence.
As I finished the project, I learned that the combination of structure, ownership, and model-driven thinking made the difference between participating in Agile and truly driving direction within it.
About Niels Hammink.
Niels is one of the business analysts at Gorilla IT who excels at structure, consistency, and decision logic. He makes trade-offs explicit, keeps requirements grounded, and ensures quality is built in from the start rather than discovered later. As systems evolve, his work keeps them understandable, maintainable, and aligned with business objectives.
By turning ambiguity into clarity, decisions into structure, and ideas into outcomes teams can actually deliver.
Business analysis that creates real alignment and drives better decisions.
